Подходы к написанию автоматизированных тестов
Есть два подхода к написанию автоматизированных тестов для нашего приложения. Первый подход заключается в том, чтобы сначала написать код, а затем написать тесты. Этот подход довольно популярен, поскольку разработчики предпочитают сначала создать функциональность или функцию, прежде чем писать тесты, чтобы убедиться, что функция работает.
Однако у нас есть другой подход, когда мы пишем тесты до того, как напишем код. Это известно как разработка через тестирование (TDD) . Это означает, что разработка приложения определяется тестами, которые мы пишем. Поэтому мы не можем добавить функциональность или возможности без предварительного написания теста.
Основной посыл TDD (Test-Driven Development — разработка через тестирование) в терминах “красной”, “синей” (в некоторых источниках используется термин “зелёная”) и “зелёной” зон описывает итеративный цикл разработки:
-
Красная зона (Red): На этом этапе вы пишете тест, который должен упасть (fail). Это тест на функциональность, которую вы еще не реализовали. Важно, что тест должен быть максимально конкретным и проверять один конкретный аспект функциональности. Красная зона сигнализирует о том, что вы начинаете с чёткого определения того, что нужно сделать.
-
Синяя/Зеленая зона (Blue/Green): Здесь вы пишете минимально необходимый код для того, чтобы пройти написанный тест. Важно писать только тот код, который требуется для прохождения теста, избегая преждевременной оптимизации или добавления лишнего функционала. Цель — сделать тест “зеленым” (пройденным). Некоторые методологии TDD разделяют этот шаг на два: “Blue” - планирование и “Green” - написание кода, минимально необходимого для прохождения теста.
-
Зеленая зона (Green): Тест проходит! Это означает, что вы успешно реализовали необходимую функциональность. Теперь можно перейти к рефакторингу.
-
Рефакторинг: После того, как тест пройден, вы можете улучшить код, не меняя его функциональность. Это может включать в себя улучшение читаемости, уменьшение дублирования кода и повышение эффективности. Важно, что после рефакторинга тест должен продолжать проходить.
Цикл повторяется: После рефакторинга вы переходите обратно к красной зоне, пишите новый тест для следующей части функциональности, и цикл повторяется.
В итоге, основной посыл: TDD — это не просто написание тестов после написания кода. Это итеративный процесс, где тесты пишутся перед кодом, заставляя разработчика чётко определить требования к функциональности и писать чистый, хорошо протестированный код. “Красная”, “синяя/зелёная” и “зелёная” зоны — это просто удобная метафора, описывающая этот итеративный цикл.
Появление разработки через тестирование
Термин «разработка через тестирование» был введен Кентом Беком в 2002 году в его книге «Разработка через тестирование на примере». С тех пор этот термин приобрел популярность в сфере веб-разработки. Несколько крупных корпораций используют эту технику из-за ее многочисленных преимуществ.
Однако внедрение TDD не происходит само собой. Разработчик должен приложить сознательные усилия. Это связано с тем, что большинство разработчиков предпочитают сначала кодировать функциональность приложения, прежде чем тестировать его. Таким образом, мы можем сказать, что TDD похожа на дисциплину, которую нужно культивировать.
〰〰〰 𓆝 𓆟 𓆞 𓆝 𓆟 𓆝 𓆟 𓆞 〰〰〰