В какой момент лучше писать тесты? Вообще, существует три подхода:
- Тесты пишутся после кода
- Тесты пишутся вместе с кодом
- Тесты пишутся до кода
В некоторых ситуациях, особого выбора нет. Например, при системном тестировании, когда тест имитирует поведение пользователей и выполняет действия в браузере. Такие тесты пишутся после кода.
В тестах более низкого уровня, интеграционных и модульных тестах, обычно можно выбирать из вариантов описанных выше. И подход "писать тесты после кода" относится к наименее полезным. Почему?
Сам процесс написания кода связан с постоянным запуском кода и проверкой того, что он работает. В самых простых, например, учебных задачах, этот запуск происходит довольно быстро.
// Легко запустить, легко проверить, что результат правильный
StringUtils.capitalize("hello"); // Hello
В реальном коде подготовка данных для проверки работы кода может занимать значительное время, минуты и десятки минут. С другой стороны, результатом работы проверяемого кода может быть что-то сложное, например, множество записей в базе данных или вывод определённой непростой структуры. Тогда каждый запуск кода на проверку превращается в целое приключение.
// Сложно подготовить данные. Сложно проверить результат работы.
// Загрузка товаров из 1C в базу данных
loadGoodsFrom1c();
Именно здесь на сцену выходит вариант "писать тесты до кода". У многих начинающих разработчиков, эта фраза вызывает ступор. Как можно писать тесты до того, как был написан код? Оказывается, можно и это даже приятно.
Допустим, мы хотим написать метод, который может повторять переданную строчку указанное количество раз:
StringUtils.repeat("$", 3); // $$$
Мы знаем что этот метод принимает на вход, мы знаем, какой у него должен быть выход. Можем ли мы уже написать тесты? Конечно!
assertEquals("$$$", StringUtils.repeat('$', 3));
Сколько займёт времени написать такой тест у опытного разработчика? Думаю секунд 15, именно столько времени мне понадобилось для кода выше. Зато теперь для проверки работы этого кода достаточно набрать ./gradlew test в консоли.
У тестирования до написания кода есть ещё одно мощное преимущество. Оно заставляет программиста в первую очередь думать о дизайне своего решения, о том, как им будут пользоваться. А не о том, как красиво он реализует всё внутри. Грамотные интерфейсы – залог успеха.
В мире разработки подход, при котором тесты пишутся до кода, называется Test-Driven Development (TDD).
TDD по задумке изобретателя этой техники подразумевает, что вся разработка состоит из повторяющегося цикла, где на каждой итерации пишется тест, который не проходит, затем дописывается код, удовлетворяющий данному тесту. После этого всё повторяется. Так, шаг за шагом, строится приложение.
Сейчас все по инерции продолжают говорить именно о таком способе. В нём тесты пишутся на все части кода с максимальной детализацией. Этот вид TDD хоть и говорит о важности дизайна, но фокусируется на конкретных методах и классах приложения вместо цельной картины. Но есть и другое TDD, где тесты на внутренние части не пишутся почти никогда. Подробнее об этом в статье в дополнительных материалах.
Сам по себе Хекслет, яркий пример того, как тесты пишутся до кода. Абсолютно во всех наших практиках на всех языках, тесты есть, а кода нет :)
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
