В какой момент лучше писать тесты? Вообще, существует три подхода. Можно писать тесты:
- После кода
- Вместе с кодом
- До кода
В некоторых ситуациях, особого выбора нет. Например, при системном тестировании тест имитирует поведение пользователей и выполняет действия в браузере — такие тесты можно писать только после кода.
В интеграционных, модульных и других низкоуровневых тестах обычно можно выбирать из вариантов, описанных выше. Считается, что писать тесты после кода — это наименее полезный подход. Разберемся, почему так.
Когда мы пишем код, его нужно постоянно запускать и проверять. Например, в самых простых учебных задачах этот запуск происходит довольно быстро:
<?php
// Легко запустить и проверить, что результат правильный
capitalize('hello'); // Hello
В реальном коде подготовка данных для проверки кода может занимать минуты и десятки минут. С другой стороны, результатом работы проверяемого кода может быть что-то сложное — например, множество записей в базе данных или вывод определенной непростой структуры. Тогда каждый запуск кода на проверку превращается в целое приключение:
<?php
// Сложно подготовить данные и проверить работу кода
// Загрузка товаров из 1C в базу данных
loadGoodsFrom1c();
Именно здесь на сцену выходит написание тестов до кода. У многих начинающих разработчиков эта фраза вызывает ступор — как можно тестировать то, чего нет?
Обсудим подробнее, как это происходит. Допустим, мы хотим написать функцию, которая может повторять переданную строчку указанное количество раз:
<?php
repeat('$', 3); // $$$
Мы знаем, что функция принимает на вход и какой у нее должен быть выход (благодаря тому, что эта функция чистая). Можем ли мы уже написать тесты? Конечно:
<?php
class SomeTest extends TestCase
{
public function testRepeat(): void
{
$this->assertEquals('$$$', repeat('$', 3));
}
}
Опытный разработчик напишет такой тест секунд за 15. Теперь для проверки работы этого кода достаточно набрать phpunit в консоли.
У тестирования до написания кода есть еще одно мощное преимущество. Оно заставляет программиста сосредоточиться на том, как построено его решение и как его будут использовать. При таком подходе мы не думаем, будет ли это выглядеть красиво внутри. Так получаются грамотные интерфейсы.
В мире разработки написание тестов до кода называют TDD (Test-Driven Development):
По задумке TDD подразумевает, что вся разработка состоит из повторяющегося цикла:
- Мы пишем первый тест
- Он не проходит
- Мы дописываем код, удовлетворяющий тесту
- Мы пишем второй тест
- И так далее
Так шаг за шагом строится приложение. Сейчас все по инерции продолжают говорить именно о таком способе. В нем тесты пишутся на все части кода с максимальной детализацией. С одной стороны, этот вид TDD ставит в приоритет дизайн. С другой стороны, он фокусируется на конкретных функциях и классах приложения вместо цельной картины. Но есть и другое TDD, где не принято писать тесты на внутренние части. Подробнее об этом вы можете почитать в статье в дополнительных материалах.
Сам по себе Хекслет — это яркий пример того, как тесты пишутся до кода. Абсолютно во всех наших практиках на всех языках, тесты есть, а кода нет :)
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
