Существующие ответы, безусловно, хороши, но я не видел, чтобы кто-то обращался к этому фундаментальному заблуждению в вопросе:
в любой момент времени все модульные тесты должны пройти
Нет. Конечно, это не будет правдой. Во время разработки программного обеспечения NCrunch чаще всего либо коричневого цвета (сбой сборки), либо красного цвета (неудачный тест).
Когда NCrunch должен быть зеленым (все тесты пройдены), это когда я готов отправить коммит на сервер управления исходным кодом, потому что в этот момент другие могут зависеть от моего кода.
Это также относится к теме создания новых тестов: тесты должны утверждать логику и поведение кода. Граничные условия, неисправные состояния и т. Д. Когда я пишу новые тесты, я пытаюсь определить эти «горячие точки» в коде.
Модульные тесты документируют, как я ожидаю, что мой код будет вызываться - предварительные условия, ожидаемые результаты и т. Д.
Если тест прервется после изменения, мне нужно решить, является ли код или тест ошибочным.
Напомним, что модульное тестирование иногда идет рука об руку с разработкой, управляемой тестами. Одним из принципов TDD является то, что сломанные тесты - ваши ориентиры. Если тест не пройден, вам нужно исправить код, чтобы тест прошел. Вот конкретный пример с этой недели:
Предыстория : я написал и теперь поддерживаю библиотеку, используемую нашими разработчиками, которая используется для проверки запросов Oracle. У нас были тесты, которые утверждали, что запрос соответствовал некоторому ожидаемому значению, что делало случай важным (это не в Oracle), и весело одобряли недействительные запросы, если они полностью соответствовали ожидаемому значению.
Вместо этого моя библиотека анализирует запрос, используя Antlr и синтаксис Oracle 12c, а затем помещает различные утверждения в само дерево синтаксиса. Такие вещи, как, он действителен (ошибки синтаксического анализа не возникали), все его параметры удовлетворяются набором параметров, все ожидаемые столбцы, считываемые средством чтения данных, присутствуют в запросе и т. Д. Все это элементы, которые проскользнули в производство в разное время.
Один из моих коллег-инженеров прислал мне запрос в понедельник, который потерпел неудачу (или, скорее, был успешным, когда он должен был выйти из строя) в выходные. Моя библиотека сказала, что синтаксис в порядке, но он взорвался, когда сервер попытался запустить его. И когда он посмотрел на запрос, было очевидно, почему:
UPDATE my_table(
SET column_1 = 'MyValue'
WHERE id_column = 123;
Я загрузил проект и добавил модульный тест, который утверждал, что этот запрос не должен быть действительным. Очевидно, тест не удался.
Далее, я отлажен тест неисправного, прошла через код , где я ожидал , что это бросить исключение, и выяснила , что Antlr была повышение ошибки на открытом Paren, просто не так , предыдущий код ожидавшим. Я изменил код, проверил, что тест теперь зеленый (прохождение) и что никто другой не прервал процесс, зафиксировал и нажал.
Это заняло, может быть, 20 минут, и в процессе я значительно улучшил библиотеку, потому что теперь она поддерживает целый ряд ошибок, которые ранее игнорировались. Если бы у меня не было модульных тестов для библиотеки, исследование и устранение проблемы могло бы занять несколько часов.