Три правила управляют разработкой через тестирование (TDD). Первое правило гласит: «Пишите производственный код только для того, чтобы неудавшийся модульный тест прошел успешно. ’. Здесь у нас есть центральный принцип TDD — мы воздерживаемся от написания поведенческого кода, у нас есть модульный тест, требующий поведения. И этот тест должен быть провален. Только после этого мы делаем тест пройденным, создавая соответствующее поведение в коде реализации.

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

В приведенном ниже примере (написанном на C# с использованием XUnit) экземпляр SalesTaxSelector выдает соответствующее исключение, когда тест вызывает свой метод Select() для идентификатора страны, для которого нет соответствующего SalesTax:

Хороший. Тем не менее, единственная причина, по которой мы можем запустить этот модульный тест, заключается в том, что

  1. У нас есть класс SalesTaxSelector, включающий конструктор по умолчанию, и
  2. 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 мощные идеи, которые помогут вам сократить путь к профессиональному программисту.