Некоторые разработчики называют Test Driven Design TDD. Но в этой статье мы будем рассматривать это как разработку через тестирование. Итак, что такое разработка через тестирование? TDD — это процесс разработки программного обеспечения, который представил Кент Бек в 1999 году. Вы можете найти его в книге Бека по экстремальному программированию. «Сначала проверьте» — основная концепция этого процесса. Таким образом, мы должны сначала написать тесты, а затем код, и из-за этого мы избежим дублирования. TDD инструктирует разработчиков писать новый код только в случае сбоя автоматизированного теста.
TDD состоит из 3 фаз:
1 – КРАСНЫЙ: сначала напишите модульный тест в случае сбоя. Невозможность компиляции - это провал.
2- ЗЕЛЕНЫЙ: напишите достаточно кода, чтобы пройти тест. На этом этапе вам нужно действовать как программисту, у которого есть одна простая задача: написать простое решение, которое сделает тест пройденным. На этом этапе вам разрешено нарушать лучшие практики и даже дублировать код. Дублирование кода будет устранено на этапе рефакторинга.
3- REFACTOR: на этом этапе вам разрешено изменять код, оставляя все тесты зелеными. Но что-то важное на этом этапе вы должны удалить дубликаты.
Эта схема представляет собой цикл разработки через тестирование. Поясним это на примере.
Я напишу этот тест на C#, но с помощью этого примера вы сможете получить основы TDD.
Сначала нужно создать новое решение и два проекта внутри. Один из них — библиотека классов, другой — модульный тест. Мой проект будет калькулятор. И я проверю деление на 0.
Это мой модульный тест, и я создаю тестовый метод, такой как Number_Divide_By_Zero_Throws_DivideByZeroException_TestMethod(), и мы ожидаем, что он вызовет исключение DivideByZeroException. Как видите, я получаю сообщение об ошибке для CalculatorDivideFunction(). Потому что я написал этот тест, а не код. Теперь я создам класс с именем CalculatorDivideFunction.
Сейчас мы находимся в КРАСНОЙ ФАзе TDD. Тесты ожидают от нас DivideByZeroExceptions. Но мы выбрасываем исключение NotImplementedException. Если мы запустим этот тест, как показано ниже.
Мы получаем сообщения об ошибках. Это была наша КРАСНАЯ ФАЗА. Мы готовы перейти к ЗЕЛЕНОЙ ФАзе.
Мы изменили метод GetResultByDivide(), и теперь он вызывает исключение DivideByZeroException(). Запустим тест.
Как видите, наша тестовая ситуация изменилась с красного на зеленый. После этого этапа вы можете реорганизовать свой код.
Каковы преимущества TDD? Когда вы сначала пишете тестовые случаи, вы более четко думаете о системных требованиях и более критично о крайних случаях. Это также более безопасный способ рефакторинга кода. При написании TDD есть тесты на определенный кусок логики.
При рефакторинге кода вы можете что-то сломать, но при таком подходе вы знаете, что тесты прикроют вашу спину. С помощью TDD вы можете создать НАДЕЖНЫЙ КОД.
Я пытался объяснить, что такое TDD, как мог. Если вы применяете TDD к своим небольшим проектам, вы можете добиться большего успеха в этой работе, потому что TDD легко освоить и сложно освоить. Так что вам стоит заняться практикой. Я собираюсь закончить эту статью цитатой.
«Не исправлять ошибки позже; исправить их сейчас». - Стив Магуайр
