Сразу оговорюсь, что при прочтении могут возникнуть мысли о капитанстве, наравне с полыханием пятой точки.

Извините уж за это, но я не могу удержаться.

Я часто встречаю позицию такого рода - “Нужно сделать покрытие 100% юнит-тестами, тогда и заживем”. Нет, не заживете.

А почему? А потому что скорость изменения бизнеса не будет вам позволять покрыть код 100% юнит-тестами, если это не замороженный проект.

Даже если вы соберетесь командой N человек и одним геройским рывком покроете функционал юнит-тестами, то где гарантия, что близжайшая бизнес задача не сделает негодными часть тестов?

И что в итоге? Вы снова собираетесь командой N-человек и правите юнит-тесты.

Также, наверняка 100% тестов не получится делать, из-за того, что вы будете уходить “в насыщение”.

То есть вы будете бесконечно приближаться к числу 100, но не будете достигать его.

98%, 99%, 99.9%… Всегда останется строчка кода, которую не покрыть юнит-тестами.

Ну и человеческий фактор. Юнит-тесты пишутся людьми, как и код. И никто не застрахован от “подгонов тестов”.

Возникает закономерный вопрос - “Как же быть?”.

А быть просто - не покрывайте код 100% юнит-тестами.

Установите планку, например 80%

“Но тогда часть функционала будет непроверена!” - скажете вы. Да, юнит-тестами она покрыта не будет.

Но! Но есть еще множество замечательных инструментов, позволяющих установить метрики качества кода, проверить его.

Давайте по порядку:

pre-commit hooks

Прекрасная вещь, которая проверяет ваш код перед совершением git-коммита.

И в случае несоответствия его каким-то правилам - отклонит коммит.

А может даже и поправит ваш код. Мощь этого инструмента воистину поражает.

Тут и проверка на pep8 (которым грешат многие разработчики любого уровня, кстати), проверка всяких yamlов-tomlов и т.д.

А самое главное, вы можете создавать свои скрипты, для проверки кода.

Например я, относительно недавно написал набор скриптов, которые проверяют python код на соответствие парадигме элегантных объектов (https://github.com/roch1990/peon).

Подробней узнать о инструменте вы можете тут - https://pre-commit.com/ .

Mutual тестирование

Производится изменение вашего кода с последующей проверкой на “изменилось ли что-то в выполнении кода или нет”.

Например у вас есть вычисление return 2 + 2. Соответственно вы ожидаете 4 где-то далее в вашем ПО.

Тут заходит злобный Mutual-демон и меняет этот кусок кода на return 2-2.

Все, выполнение программы ломается. Или нет?

Если не сломается, то возможно что-то у вас в коде сделано не так.

Из минусов такого тестирования могу лишь указать на затраты на производительность - мне удалось положить гитлаб раннер запускам этих тестов.

Проверить это вы можете (не ухайдакивание раннера :), например воспользуясь библиотекой mutmut для python3 (https://pypi.org/project/mutmut/)

Интеграционное тестирование

Казалось бы - “Да ладно, мы все знаем про интеграционное тестирование!”. Но все ли его делают? И делают ли правильно?

В интеграционном тестировании вы не должны проверять просто тыкая метод палочкой “Ой, отправлю запрос, что-то прилетело в ответ - отлично”.

Постарайтесь охватить большинство бизнес-процессов. Верные ответы, ошибки. Пусть у вас не будет весь возможный перебор входных параметров запросов (вдруг у вас есть какие-то опциональные).

Не стремайтесь писать отдельное ПО для проведения интеграционного тестирования, вместо написания отдельных модулей, чтобы они содержались в вашем ПО “из-коробки”.

Пусть это будет bash-скрипт/perl-скрипт, хоть ПО на С++. Главное, чтобы проверка производилась (ну и не вставали волосы дыбом у команды от выбранной реализации).

Security тесты

Это очень редкий зверь в современном мире, что очень зря. Сколько сейчас новостей о утечках информации из-за обычных простых ошибок в коде.

Посмотрите любую ленту новостей, за ближайшие неделю-месяц вы обязательно найдете такую новость.

Чтобы избежать этого - добрые люди придумали программные пакеты, которые проверяют ваш код на common security issues.

Удобно, не правда ли? Добавляете одну строчку в вашу сборку и смотрите отчет, никаких лишних телодвижений.

И в будущем у вас будет меньше проблем с безопасностью.

Проверить свой код на python можно, используя библиотеку bandit.

Статический анализ

В современном мире это уже чуть ли не обязательный инструмент, который нужно использовать для вашего кода.

И технический долг посчитает, и надежность кода, и укажет на уязвимости.

Вообщем выбираете себе подходящий инструмент (благо их сейчас вагон и маленькая тележка, например sonarqube и вперед за приключениями.

Таким образом, кроме одного этапа тестирования, у вас будет, как минимум 5.

Пусть это не покроет весь функционал (останется какая-то гадость, наверняка), но вероятность достать белый шарик из коробки, с 5 попыток гораздо выше, чем с 1й попытки.

В данной статье я целенаправленно не затронул такие вещи как:

  • performance testing
  • ci/cd
  • документация
  • мониторинг
  • code review

Хотя они тоже привносят свой посильный вклад в качество кода.

Но это тема для отдельного разговора.

Данная статья не претендует на научность (пока), но её цель - чтобы хотя-бы у одного разработчика что-то зашевелилось в голове и он решил попробовать разнообразить проверки своего кода.

Если тема понравилась и интересно почитать что-то подобное еще, либо раскрыть что-то поподробнее - пишите комментарии, ставьте лайк.

Всем мир и огнетушителей. Я не тролль :)

P.S.: Ах да, забыл привести вам моё вдохновение.