Сразу оговорюсь, что при прочтении могут возникнуть мысли о капитанстве, наравне с полыханием пятой точки.
Извините уж за это, но я не могу удержаться.
Я часто встречаю позицию такого рода - “Нужно сделать покрытие 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.: Ах да, забыл привести вам моё вдохновение.