Данный список запаховболее сфокусирован на выполнении принципов самого TDD процесса, чем на содержимом тестов. Без сомнения, существует множество подобных запахов; я же выбрал наиболее часто встречающиеся по правилу 7 (+/- 2).
- Покрытие кода тестами как цель. Если вы придерживаетесь принципов TDD, то должны получать практически 100% покрытие нового кода тестами даже без использования специальных инструментов для проверки. Существующий код - это другая история. Как получаются системы с низким процентом покрытия тестами? Если начать гнаться за покрытием кода тестами, можно только ухудшить ситуацию: увеличение числа тестов за счет их качества; тесты падают при внесение изменений в систему; часть тестов остаётся поломанными, сводя к нулю смысл самого тестирования.
- Отсутствие зелёной полосы в течении ~10 минут. Размер теста - это одно из наиболее общих заблуждений в TDD. Цель теста - двигаясь маленькими шагами вперёд получать мгновенный фидбэк. Если в среднем цикл разработки теста занимает больше 10 минут, то вы не совсем понимаете, что значит итеративное наращивание функционала. Если вы пишите тест уже 10 минут, остановитесь, вернитесь к последней зеленой полоске и начните двигаться вперёд более мелкими шагами.
- Создание сразу рабочих тестов. В TDD отрицательный фидбек означает, что ваши предположения верны. Написать рабочий тест - лучший способ потратить время зря. Много раз я сталкивался с тем, что разработчик сразу писал рабочий тест, но его код оставался полон багов.
- Недостаточный рефакторинг. Если вы тратите пять минут на написание продакшн-кода, то вы должны потратить еще несколько минут на рефакторинг. Даже если кажется, что всё идеально, посмотрите вокруг - воспользуйтесь шансом отрефакторить код.
- Пропуск чего-то слишком лёгкого (или сложного) для тестирования. "Это обычный геттер, ничего страшного" или "Это ну очень сложный алгорит, понятия не имею, как его тестировать, лучше пропустить этот кусок." Простота часто скрывает под собой проблемы: может, это не такой уж и обычный геттер, а ошибка в реализации ленивой инициализации? В сложных участках кода чаще всего и находятся проблемы. Какой смысл тестировать только те вещи, которые легко тестируются? Внесение изменений наиболее дорого обходится в сложных участках системы, тесты же нужны для того, чтобы сделать разрабатываемую систему стабильной и уменьшить затраты на сопровождение.
- Тестирование методов, а не поведения. Это распространённая проблема начинающих тэдэдэшников. Они пишут тест testForSomeMethod, внутри которого создают контекст и что-то ассертят. Позже они добавляют в этот же тест вызов
someMethod()с разными входными данными и добавят в комментарий новые детали. Кроме того, что это может привести к ненужным зависимостям, такой подход усложняет понимание смысла теста и дальнейшее сопровождение. - Написание тестов после кода! По определению, это уже не TDD. Но начинающие тэдэдэшники по старой привычке часто пишут код без написания неработающего теста. Почитайте "Why TAD Sucks" (TAD = Test-After Development) , чтобы найти для себя несколько причин начинать с написания неработающего теста.
0 коммент.:
Отправить комментарий