Проваливание тестов должно сделать непрерывный сбой сборки?

Если Вы чувствовали, что случай был достаточно важен для записи теста для, то, если тот тест перестал работать, программное обеспечение перестало работать. На основе этого одного, да, это должно считать сборку отказом и не продолжиться. Если Вы не используете то обоснование, то, кто решает, какие тесты не важны? Где строка между, "если это перестало работать, хорошо, но если это перестало работать, это не"? Отказ является отказом.

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

Хотя можно сделать сборку в testing/bugfixing целях.

Я думаю, что хорошая установка как Ваша должна всегда создавать успешно, включая все переданные модульные тесты.

Как сказанный Gamecat, следуют за самой сборкой, но этот код никогда не должен переходить к производству.

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

В нашей команде у нас есть простая политика: если все тесты не передают, мы не переходим к производству с кодом. Это - также очень простое для понимания для нашего менеджера проектов.

По-моему, это действительно зависит от Ваших Модульных тестов... если Вашими Модульными тестами являются действительно Модульные тесты (как, они должны быть => "ссылка на бесконечные книги ;)") затем сборка должна перестать работать, потому что что-то не ведет себя, как должен...

но чаще всего (к сожалению, к часто замечаемому), в таком количестве проектов эти модульные тесты только покрывают некоторые 'края' и/или являются интеграционными тестами, затем сборка должна продолжиться (да, это - субъективный ответ ;)

короче говоря: Вы знаете, что модульные тесты прекрасны: сбой; еще: основываться

Все ответы были большими, вот то, что я решил сделать:

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

• Сборка может перестать работать, если какие-либо тесты перестали работать, следовательно уменьшая вонючее
• Тесты, которые проигнорированы, должны быть защищены менеджеру проектов (кто бы ни является главным),
• Любые тесты, которые проигнорированы, отмечены специальным способом

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

Что я на самом деле сделал: зафиксированный поврежденные тесты.

Настоящая проблема с Вашими провальными тестами. У Вас не должно быть модульного теста, где нормально перестать работать, потому что это - пограничный случай. Решите, важен ли пограничный случай или не - если не затем удаляют модульный тест; если да затем исправляют код.

Как некоторые из других подразумеваемых ответов, это - определенно запах кода, когда модульные тесты перестали работать. Если Вы будете жить с запахом, то Вы, менее вероятно, определите следующую проблему