Как вы справляетесь с TDD в непрерывной интеграции?

Question

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

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

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

Какая процедура предлагается в такой ситуации?

Answer 1

Не выбирайте все интерфейсы заранее. Развивайтесь постепенно в типичном ритме TDD: напишите тест; сделать тестовый проход; рефакторинг. Это должно держать все в хорошем состоянии, полоса всегда будет зеленой, и вы можете проверить код, не беспокоясь о том, что вы сломаете сборку.

Требуется другой стиль написания кода, но со временем вы привыкнете к ритму.

Answer 2

Как насчет того, чтобы пропустить те тесты, которые, как вы знаете, не пройдут, потому что функциональность в настоящее время отсутствует?

Сделайте очевидным, что вы тоже пропускаете тесты! Действительно заставить его кричать "как застрявшая свинья", как говорят в Оз! (-:

По мере добавления функциональности включайте соответствующие тесты и сохраняйте «зеленую полосу»!

Вот еще одна замечательная статья в The Pragmatic Programmers, в которой рассказывается о том, как сделать разбитые окна очевидными для других.

НТН

ура

Rob