Три правила управляют разработкой через тестирование (TDD). Первое правило гласит: «Пишите производственный код только для того, чтобы неудавшийся модульный тест прошел успешно. ’. Здесь у нас есть центральный принцип TDD — мы воздерживаемся от написания поведенческого кода, у нас есть модульный тест, требующий поведения. И этот тест должен быть провален. Только после этого мы делаем тест пройденным, создавая соответствующее поведение в коде реализации.
Часто довольно просто создать неудачный модульный тест, требующий определенного поведения, когда у нас уже есть определения классов и методов.
В приведенном ниже примере (написанном на C# с использованием XUnit) экземпляр SalesTaxSelector
выдает соответствующее исключение, когда тест вызывает свой метод Select()
для идентификатора страны, для которого нет соответствующего SalesTax
:
Хороший. Тем не менее, единственная причина, по которой мы можем запустить этот модульный тест, заключается в том, что
- У нас есть класс
SalesTaxSelector
, включающий конструктор по умолчанию, и SalesTaxSelector
имеет общедоступныйSelect()
метод.
Это здорово, но как мы их получим?
Испытания строительных лесов
Начнем сверху; самое основное требование — как нам получить класс SalesTaxSelector
? Какой возможный модульный тест мы могли бы написать — и в этом суть — чтобы подтолкнуть нас к defineSalesTaxSelector
?
Подойдет ли этот тест?
Минуточку; это не сработает. Модульный тест не будет компилироваться; у нас нет определения для SalesTaxSelector
!
Не побуждает ли эта ошибка компиляции к созданию класса SalesTaxSelector
?
Это, безусловно, так.
Следовательно, как только мы напишем простое определение класса, неудавшийся модульный тест будет пройден:
Вы заметили, что мы генерируем только реализацию, определение пустого класса для SalesTaxSelector
, как указано в Правиле 3 Трех правил TDD.
Итак, чтобы следовать правилам TDD, нам понадобился модульный тест, который заставит нас реализовать SalesTaxSelector
определение — тест скаффолдинга.
В строительной отрасли используются подготовленные леса для придания формы залитому бетону до тех пор, пока он не высохнет. Как только бетон затвердеет, рабочие убирают строительные леса, и бетонная конструкция будет стоять прочно.
Точно так же нам нужны скаффолдинговые тесты только для создания необходимой программной инфраструктуры — класса или методов — после этого они нам больше не нужны.
Итак, мы столкнулись с скаффолдинг-тестом для файла . Давайте воспользуемся подходом модульного тестирования строительных лесов для создания Select()
SalesTaxSelector
:
И снова модульный тест сталкивается с ошибкой компиляции для неизвестного метода Select()
, которую быстро устраняют, реализуя базовую версию нашего SalesTaxSelector
:
Опять же, обратите внимание, как мы представляем метод Select()
в самых простых терминах:
Требуемая специфика реализации метода Select()
будет получена в результате дальнейших модульных тестов. Существуют скаффолдинговые тесты для генерации определений классов и общедоступных методов.
Кроме того, обратите внимание, что в Scaffolding Tests нет утверждений. Мы не проверяем конкретное поведение, как обычно делаем с модульными тестами, но здесь мы хотим только создавать классы и методы, противодействуя ошибкам компиляции с помощью реализаций классов и методов.
Это необходимо?
На первый взгляд, определение тестов скаффолдинга, а затем обеспечение их прохождения с помощью тривиальных определений классов и методов выглядит как работа. Зачем возиться со строительными тестами, когда мы понимаем класс или метод, который хотим определить?
Я постоянно слышу такие возражения по поводу тестов строительных лесов. Вот причина, по которой я их храню:
Избегайте скользкого склона
Переход от строгого применения TDD, когда мы неукоснительно следуем трем правилам и поэтому пишем весь код реализации только тогда, когда у нас есть контрольный тест, чреват проблемами. По моему опыту, новички в TDD, которые отказываются от строительных тестов, как правило, быстро возвращаются к написанию слишком большого количества кода без модульных тестов до такой степени, что они больше не практикуют TDD. Последовательное применение трех правил и доверие к процессу TDD, а не поиск коротких путей, с большей вероятностью приведет к успеху TDD.
Заключение
Модульные тесты, которые заставляют нас создавать тестируемые классы и их общедоступные методы, называются скаффолдинговыми тестами. Этот конкретный тип теста TDD помогает нам оставаться верными правилу, согласно которому мы не должны писать код, если у нас нет неудачного теста. Скаффолдинг-тесты не кодируют ожидаемое поведение программы; поэтому мы можем удалить их, как только они выполнят свою работу.
Если вам понравилась эта статья, пожалуйста, поставьте несколько аплодисментов — и кучу аплодисментов, если она вам понравилась! :) Большое спасибо.
Подпишитесь на мою рассылку, чтобы ускорить свою карьеру в разработке программного обеспечения.
При регистрации вы получите мое руководство "Путь к мастеру-программисту", содержащее 3 мощные идеи, которые помогут вам сократить путь к профессиональному программисту.