Введение

Разработка через тестирование — это эффективный метод обеспечения хорошо протестированного и поддающегося рефакторингу кода. Основная идея заключается в том, что вы начинаете разработку с написания тестов. Эти тесты четко документируют ожидания и создают критерии для успешной реализации. Если все сделано правильно, вы можете четко определить ожидаемый ввод/вывод функции перед написанием любого кода. Это имеет несколько непосредственных преимуществ:

• Вы тщательно продумываете интерфейс взаимодействия с вашим кодом и проектируете его так, чтобы его можно было тестировать
• Когда вы начинаете писать код, ваш процесс не прерывается ручным тестированием или пошаговым выполнением логики выполнения для прогнозирования результата. Вместо этого вы просто запускаете тесты
• Прохождение теста становится целью, достижение которой приносит удовлетворение. Разбивка процесса на ряд четко определенных и достижимых этапов делает работу более приятной
• Избегайте лени и излишней самоуверенности после реализации, которые могут помешать вам протестировать код

Теперь, когда вы убедились в преимуществах, вы можете приступить к разработке через тестирование (TDD), выполнив следующие действия:

1. Написание или изменение тестов
2. Проверьте, не пройден ли тест
3. Напишите минимальное количество кода, чтобы тесты прошли успешно

Эти шаги выполняются циклично, поэтому вы всегда добавляете больше тестов, чтобы бросить вызов текущей реализации.

Последний шаг, который требует написания минимального объема кода, может стать утомительным, если следовать ему строго. Важно понять, почему существует это правило, прежде чем вы сможете определить, когда уместно от него отступить.

Простой пример

Вам поручено реализовать функцию Add(x, y int) int. Прежде чем перейти к реализации и просто вернуть x y, напишите простейший тест: 1 1 == 2. Какая же самая простая реализация пройдет этот тест? Это просто возврат 2. Теперь ваши тесты пройдены!

На этом этапе вы понимаете, что вам нужно больше тестов, поэтому ускоряете темп и добавляете еще несколько:

• 1 2 == 3
• 100 5 == 105

Теперь ваши тесты терпят неудачу, поэтому вам нужно исправить реализацию. На этот раз вы не можете просто вернуть 3 или 105, поэтому вам нужно найти решение, которое будет работать для всех тестов. Это приводит к реализации: return x y.

Хотя в тривиальном примере это кажется слишком утомительным, строгое соблюдение этого метода заставило вас написать несколько тестов вместо того, чтобы просто доверять своей реализации. Конечно, ваша первоначальная идея вернуть x y сработала бы, но суть в том, чтобы переучить себя полагаться на тесты, а не на собственное понимание кода. В реальном мире вы не единственный, кто работает над этим фрагментом кода, и вы неизбежно забудете детали реализации. Этот процесс заставляет вас писать больше тестов и думать о новых способах сломать простую реализацию.

Со временем вы наберетесь опыта и научитесь находить баланс, который работает в различных сценариях, с которыми вы сталкиваетесь. Вы вернетесь к полной реализации функций и обнаружите, что у вас меньше ошибок и вы пишете больше поддерживаемого кода.

Пошаговое TDD для HTTP API

Давайте рассмотрим более сложный пример использования TDD для HTTP REST API. В этом пошаговом руководстве используется моя платформа Go, babyapi, но эти концепции можно применять где угодно.

babyapi использует дженерики для создания полноценного CRUD API на основе структур Go, что упрощает создание полноценного REST API и клиентского CLI. В дополнение к этому пакет babytest предоставляет некоторые инструменты для создания сквозных тестов таблиц API. Использование TDD на уровне API позволяет полностью протестировать уровни HTTP и хранилища нового API или функции одновременно.

Отказ от ответственности: поскольку babyapi выполняет большую часть реализации, а также используется для создания тестового шаблона, технически мы не начинаем с TDD. Однако мы увидим, насколько это полезно при добавлении поддержки запросов PATCH в наш API.

1. Создать новый проект Go
   

2. Создайте исходный файл main.go, используя простой пример babyapi
   

3. Используйте интерфейс командной строки для создания шаблона теста
   

4. Реализуйте каждый тест, заполнив заполнители ожидаемым JSON
   

5. Запустите тесты и убедитесь, что они пройдены!

6. Поскольку PUT является идемпотентным, он требует включения всех полей. Чтобы избежать этого, мы хотим добавить поддержку переключения запросов «Завершено с PATCH». Начнем с добавления простого теста того, как, по нашему мнению, будет выглядеть эта функция
   

7. Этот тест не пройден, поскольку babyapi по умолчанию не поддерживает PATCH. Мы можем это исправить, внедрив Patch для структуры TODO. Поскольку мы определили нашу функцию с помощью двух тестов, наша самая простая реализация — это не просто установка Completed = true, и мы должны использовать значение из запроса
   

8. Теперь мы можем изменить статус выполнения задачи TODO, но по-прежнему не можем использовать PATCH для изменения других полей, как показано в этом новом наборе тестов
   

9. Обновите патч, чтобы настроить остальные поля
   

10. Наши тесты по-прежнему терпят неудачу, поскольку мы всегда обновляем TODO с полями запроса, даже если они пусты. Исправьте это, обновив реализацию для проверки пустых значений
    

11. Новый тест UpdateWithPatch пройден, но наши предыдущие тесты завершились неудачей. Поскольку мы изменили значение Completed на *bool, TODO, созданные с пустым значением, будут отображаться как null
    

12. Реализовать рендеринг для TODO, чтобы мы могли считать ноль ложным
    

Внедрение функции PATCH при разработке через тестирование привело к созданию надежного набора тестов и хорошо реализованной функции. Поскольку мы начали с определения ожидаемых входных и выходных данных запроса PATCH в тестах, было легко увидеть проблемы, вызванные отсутствием проверки пустых значений в запросе. Кроме того, наши ранее существовавшие тесты могли защитить от критических изменений при изменении типа Completed на *bool.

Заключение

Разработка через тестирование — это эффективный подход для создания полностью протестированного и правильного кода. Начав с тестирования, мы можем гарантировать, что каждый фрагмент кода спроектирован так, чтобы его можно было тестировать, а не оставлять тесты на второй план.

Если вы не решаетесь использовать TDD, вот несколько идей для начала:

• Попробуйте это в простых сценариях, где ввод/вывод функции понятен, а реализация не слишком сложна. Вы можете написать надежный табличный тест для различных типов ввода/вывода, с которыми можно столкнуться. Наличие четкого представления различных сценариев может упростить реализацию
• Если вы исправляете новую ошибку, вы уже обнаружили пробел в своем тестировании. Начните с написания теста, который бы выявил эту ошибку в первую очередь. Затем пройдите этот тест, не нарушив ни одного существующего теста.
• Подобно примеру babyapi, вы можете использовать TDD для тестов API высокого уровня. Как только вы определите ожидаемый запрос/ответ, вы можете возобновить обычный процесс разработки для более детализированных частей реализации

Даже если TDD не очень подходит для того, как вы пишете код, это все равно мощный инструмент, который нужно иметь под рукой. Я советую вам хотя бы потратить некоторое время на то, чтобы опробовать его и посмотреть, как это повлияет на ваш процесс разработки.