Внешний TDD: Должен ли я регистрироваться в случае неудачных приемочных испытаний?

Question

Таким образом, вы начинаете с неудачного приемочного испытания и наращиваете функцию с помощью модульных тестов до тех пор, пока приемочный тест не пройдет. Но когда вы проходите модульные тесты, стоит ли вам проверять систему контроля версий? Если да, помечаете ли вы приемочный тест как игнорируемый (и если да, то где? В коде или на сервере сборки)? Как это вписывается в непрерывную интеграцию?

Answer 1

Нет, вы не должны проверять в проваливающемся тесте, в среде Continuous Integration вы должны постоянно сохранять код повторяемым, по определению провальный приемочный тест показывает, что код в настоящее время не выпускается.

Несмотря на сбой, приемочный тест показывает, что система еще не реализовала эту функцию; когда это пройдет, мы закончили.
_{Растущее объектно-ориентированное программное обеспечение под руководством тестов Стива Фримена и Ната Прайса}

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

Я бы не сказал это так сильно, но это в значительной степени подводит итог -

43. Делитесь кодом только тогда, когда будете готовы. Никогда не проверяйте код, который не готов для других. Умышленная проверка кода, который не компилируется или не проходит его модульные тесты, должна рассматриваться как преступная халатность проекта.
_{Практика Agile Developer, разработанная Venkat Subramaniam и Andy Hunt.}

Answer 2

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

Платформы тестирования, которые я использую сегодня, решают эту проблему, предлагая способы помечать тесты как невыполненные:

• призвание pending в определении шага Cucumber пропускает оставшуюся часть шага и сценария и печатает предупреждение, чтобы напомнить вам. Конфигурация Cucumber по умолчанию также игнорирует сценарии с тегами @wip, хотя этот механизм не производит напоминание предупреждение.
• Аналогично, в RSpec есть несколько способов пропустить примеры.

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