Разработка

Что такое Разработка через тестирование (Test Driven Development, TDD)

Test Driven Development- это процесс, который использует тесты для проектирования и разработки вашего приложения.

Опубликовано

4 года назад

24.11.2020

Автор:

AppTractor

Зачем тестировать? Цель написания тестов — убедиться, что код, который вы пишете, работает должным образом, и вы ничего не сломали при добавлении новых функций или рефакторинге кода. Автоматизация является неотъемлемой частью разработки программного обеспечения, тогда почему мы должны продолжать проводить ручные тесты снова и снова, имея шанс пропустить некоторые важные сценарии тестирования? Вместо этого позвольте роботам делать скучные задания за вас.

Если вы написали комплект тестов, и он отработал, вы можете быть уверены, что все ваше приложение ведет себя так, как ожидалось.

Что такое Разработка через тестирование (Test Driven Development, TDD)

Тесты, вероятно, лучший способ добиться надежности растущей кодовой базы. Чтобы сэкономить время и добиться чистого кода, мы рекомендуем писать код с использованием Test Driven Development.

TDD — это процесс, который использует тесты для проектирования и разработки вашего приложения. Циклы разработки в нем называются Красный, Зеленый, Рефакторинг (Red, Green, Refactor).

Красный, Зеленый, Рефакторинг

Давайте рассмотрим на примере этот поток красный, зеленый и рефакторинг.

Например, представьте, что вы хотите создать функцию sort_array (), которая может сортировать массив в порядке возрастания.

Красный

Подумайте о том, что вы хотите сделать.

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

ВХОД: [34, 3, 12, 2]
ВЫХОД: [2, 3, 12, 34]

Когда вы запустите тест, вы увидите такую ошибку.

Зеленый

Подумайте, как пройти тесты.

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

После реализации функции sort_array () мы должны увидеть сообщение о прохождении теста, которое выглядит следующим образом.

Рефакторинг

Подумайте, как улучшить вашу существующую реализацию.

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

Снова Красный.

Ожидаемый результат не соответствует фактическому результату, который мы получаем…

Ожидаем: [3, 8, 21, 99]
Получаем: [2, 3, 12, 34]

Это потому, что мы возвращаем первый отсортированный массив! Не заботясь о других примерах (не реализован какой-либо алгоритм сортировки). Найдите минутку, чтобы подумать, как подойти к рефакторингу функции sort_array () и написать код для сортировки массива в порядке возрастания.

Теперь, если вы снова запустите rspec, вы увидите, что оба тестовых примера проходят.

По мере рефакторинга sort_array (), когда мы завершаим процесс рефакторинга и снова запустим наш набор тестов, мы должны получить следующий вывод:

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

3 закона Разработки через тестирование (Test Driven Development)

Вот они:

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

Трудно сказать, как они работают, просто прочитав их. Попробуйте сами, почувствуйте разницу.