В какой момент лучше писать тесты? Вообще, существует три подхода:
- Тесты пишутся после кода
- Тесты пишутся вместе с кодом
- Тесты пишутся до кода
В этом уроке мы разберемся, в чем особенности каждого подхода.
Подход «Тесты после кода»
В некоторых ситуациях особого выбора нет. Например, при системном тестировании тесты должны имитировать поведение пользователей и выполнять действия в браузере. Такие тесты пишутся после кода.
В интеграционных, модульных и других тестах низкого уровня программист может выбирать из вариантов, описанных выше.
Подход «Тесты до кода»
Подход «писать тесты после кода» относится к наименее полезным. Разберемся, почему так. Сам процесс написания кода связан с постоянным запуском кода и проверкой того, что он работает. В самых простых задачах, этот запуск происходит довольно быстро:
# Легко запустить и легко проверить результаты
capitalize('hello') # Hello
В реальном коде подготовка данных для проверки работы кода может занимать минуты и десятки минут. С другой стороны, результатом работы проверяемого кода может быть что-то сложное — например, множество записей в базе данных или вывод определенной непростой структуры.
Тогда каждый запуск кода на проверку превращается в целое приключение:
# Сложно подготовить данные, сложно проверить результат работы
# Загрузка товаров из 1C в базу данных
load_goods_from_1c()
Именно здесь на сцену выходит вариант «писать тесты до кода». У многих начинающих разработчиков эта фраза вызывает ступор. Как можно писать тесты до того, как написан код? Оказывается, можно.
Допустим, мы хотим написать функцию, которая может повторять переданную строчку указанное количество раз:
repeat('$', 3) # $$$
Мы знаем две важные вещи:
- Что это чистая функция
- Что именно эта функция принимает на вход
Зная это, мы уже можем написать тесты:
def test_repeat():
assert repeat('$', 3) == '$$$'
Опытный разработчик напишет такой код за 15-20 секунд. Зато теперь для проверки работы этого кода достаточно набрать uv run pytest в консоли.
У тестирования до написания кода есть еще одно мощное преимущество — оно заставляет программиста думать не о коде, а о дизайне своего решения. Это подталкивает программиста размышлять о том, как люди будут пользоваться его приложением. Так создаются грамотные интерфейсы, а это часто залог успеха.
Подход «Тесты во время кода»
В мире разработки есть подход, при котором тесты пишутся во время кода. Он называется разработкой через тестирование (Test-Driven Development или TDD):
По задумке изобретателя этой техники разработка через тестирование подразумевает, что вся разработка состоит из повторяющегося цикла:
- На каждой итерации пишется тест
- Тест не проходит
- Программисты дописывают код, удовлетворяющий этому тесту
После этого все повторяется. В итоге шаг за шагом строится приложение.
Сейчас все по инерции продолжают говорить именно о таком способе. В нем тесты пишутся на все части кода с максимальной детализацией. Этот вид TDD говорит о важности дизайна, но фокусируется на конкретных функциях и классах приложения вместо цельной картины.
Но есть и другой подход к TDD, где тесты на внутренние части не пишутся почти никогда. Подробнее об этом в статье в дополнительных материалах.
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
