Недавно прочитал интересную и провокационную статью на Medium, которая привлекла необходимое внимание читателей.
Он короткий - прочтите его, чтобы понять, почему я сейчас излагаю вам эти очевидные моменты.
Для тех, у кого нет времени, моя интерпретация статьи: автор не видит причин следовать разработке через тестирование и считает это одной из ненужных церемоний племени мастеров программного обеспечения.
И, честно говоря, TDD может раздражать. Я не следую ему за каждым фрагментом кода. Я не заставляю свою команду писать модульные тесты для всего, что мы доставляем. Но это отличный инструмент в руках опытного разработчика / команды.
Читайте дальше, чтобы узнать, почему не каждый может заниматься TDD.
В основе каждого продукта должно лежать автоматическое тестирование.
Несколько моментов для объяснения этого утверждения:
- Дизайн кода. У всех были эти проблемы: поведение, которое нельзя имитировать в модульном тесте, слишком много зависимостей для его создания, метод, который ничего не делает, кроме как очень важно. Волшебным образом это выглядит естественно в потребительском классе. Пока вы не напишете для этого тест ... Уменьшите масштаб, сделайте шаг назад и просмотрите общую картину. Внезапно вы можете увидеть все: тесная связь, плохой дизайн, неправильная реализация шаблона. Тесты выявляют запахи кода, которые в противном случае могли бы остаться незамеченными. Ранние модульные тесты - предотвратите их.
- Документация. Нет лучшего способа документировать код, чем написать для него хороший модульный тест. Когда вы начинаете с хорошего теста, вы начинаете с жизненной документации. Когнитивная сложность кода - важный показатель, который должен измерять каждый проект. Естественная эволюция производственных систем увеличивает сложность. Чтобы ускорить процесс адаптации и обеспечить постепенный вход в сложную экосистему, тесты представляют собой прекрасную документацию без необходимости понимания реализации, написанную дюжиной разных разработчиков. У тестов всегда меньшая когнитивная сложность, чем у кода, который они покрывают.
- Выполнение критериев приемки. Разработчики постоянно отвлекаются на дюжину вещей: встречи, обзоры кода, электронные письма, YouTube, Medium, Twitter, назовите это - мы делаем это. И это влияет на наш уровень внимания и понимание исходного и целевого состояния дизайна функции. Позвольте бизнес-требованиям управлять реализацией и проверять ее с помощью критериев приемлемости в коде. Основой модульных тестов должны быть четко определенные критерии приемки. Он определяет направление развития, минимальные требования к качеству и функциональные требования для того, чтобы код был готов к работе.
- Рефакторинг и обслуживание производственной системы. Это важная часть, которая сама по себе является хорошей причиной для вашей команды начать инвестировать в TDD и модульное тестирование: насколько вы уверены, что срочное исправление, которое вы развернули для PROD, не вводит неожиданное поведение? Сотни ручных тестов не помогут. И подумайте о вложении времени и усилий. Ответ - комбинация автоматических, модульных и системных тестов. Если существующая функциональность нарушена - вы узнаете об этом после внесения изменений в более низкие среды. Нет лучшего способа обеспечить хорошее качество продукции, чем начать с автоматизации контроля качества. Кроме того, вы не сможете полностью использовать CI / CD без автоматизации тестирования.
- Общий язык. Еще один важный аспект написания тестов - установление общего языка в команде. Люди, имеющие опыт работы в этой области, знают - всегда есть несколько способов решить любую вычислительную задачу. Каждое решение имеет свои преимущества. И, честно говоря, не имеет значения, как это реализовано в более широком масштабе (если только вы не продаете свой код-арт как NFT). Важны результат и поведение развернутого решения. Рассматривайте модульный тест как презентацию на лифте, описывающую ваше решение для кого-то без опыта работы в проекте. Общая структура ваших рассказов [модульные тесты] позволяет легко понять идею новичку. а также опытный разработчик продукта.
- Общие обязанности. Несмотря на то, что каждый разработчик привязан к своему творению, индивидуальное владение кодом - это плохо. Команды должны стремиться к совместным знаниям и ответственности. И тесты - отличный способ обеспечить это: каждый неудачный тест - это ответственность разработчика, который внес изменения, чтобы исправить неудачный тест. Не имеет отношения к тому, кто написал исходный код и тест, и какая область приложения затронута. Команда разделяет ответственность за создание зеленого качества.
Вам нужно начинать с модульных тестов или использовать их везде?
Несмотря на то, что написание модульных тестов дает огромные преимущества, а использование TDD не всегда дает преимущества, перевешивающие недостатки:
- Сопровождение тестов и интеграция в SDLC. Первое, что вы слышите от разработчиков, у которых был плохой опыт работы с TDD, - это ужасно сложно поддерживать модульные тесты. Вы пишете больше кода, и больше кода означает больше ошибок и исправлений для него. Это никому не нравится. Люди быстро теряют энтузиазм к разочарованию после нескольких раундов исправлений «неработающих тестов». Одна из основ успешной реализации TDD - интеграция в процесс CI / CD. Без него ваши тесты быстро устареют и станут бесполезными. Неудачные тесты должны блокировать включение пул-реквеста в основной репозиторий / ветку. Если у вас нет этой автоматизированной системы, вы полагаетесь только на энтузиазм и добрую волю своей команды. Под давлением у команды не будет столько доброй воли, сколько вам хотелось бы.
- Внедрение TDD в существующих системах. Работа Сизифа - реализовать модульное тестирование в существующей системе без культуры автоматизации тестирования и инфраструктуры CI / CD. Даже если кто-то обнимает камень и никогда не сдается, стоит ли оно того? Как всегда, смотря по обстоятельствам. Основным фактором будет размер кодовой базы - небольшие проекты все еще можно« преобразовать » в хорошую сторону, но для крупных предприятий, вероятно, уже слишком поздно. Разве что это приоритетная и стратегическая задача для коллектива. Лучше подумать о том, чтобы потратить больше времени на тестирование системы и интеграции.
- Охват кода и командный настрой. Один из самых любимых, но злых показателей модульного тестирования - это покрытие кода. Менеджеры обожают это, разработчики следят за этим. Но показывает ли этот номер что-нибудь полезное? Не совсем. В ситуации, знакомой многим: вы продвинули и убедили свою команду, что TDD приносит пользу продукту. Все согласны, и первый вопрос, который вы слышите: «Сколько тестов нам нужно в TDD?». В большинстве случаев случается очень плохое - покрытие кода сводится к нулю. С этого момента название игры - достичь этой волшебной отметки желаемого покрытия кода. Часто приводят к тестам на «покрытие кода» - тестам, которые вызывают как можно больше кода в самых глубоких уголках алгоритма. Не подкреплено сценариями использования или логикой, просто для охвата. Все плюсы перечисленных мною тестов сразу выкидываются в окно.
- Плохие тесты хуже, чем отсутствие тестов. Решающий момент. Без надлежащего руководства и целей группы модульного тестирования есть риск, что в конечном итоге придется поддерживать дополнительный код без реальной пользы для качества системы. А тот факт, что нет никакой пользы, быстро оттолкнет людей от модульного тестирования еще дальше. Если тесты не входят в корпоративную культуру, вы не будете делиться знаниями, и вы станете более жесткими в своем коде, тестах и обслуживании в будущем. Модульные тесты, написанные ради метрики покрытия кода, - ненужное зло.
Резюме
Рой Ошеров назвал модульное тестирование искусством. И он прав. Чтобы освоить TDD и модульное тестирование, вам придется пройти многочисленные ката и повторения. И только после того, как вы усвоите работу и овладеете ею, вы начнете получать удовольствие от процесса и использовать его в своем ремесле.
Как такой подход сочетается с современным девизом «строить быстро, быстро терпеть неудачу»? Я оставлю этот вопрос вам.
Если вам понравилась моя статья или есть комментарии по теме - подписывайтесь, ставьте лайки и комментируйте!
