Хорошо когда код покрыт тестами. Хорошо когда кроме модульных тестов есть еще интеграционные, функциональные, UI-тесты и другие. Но должны ли тесты всегда проходить успешно? Казалось бы, очевидный ответ - да. Но не все так просто…
Хороший тест должен выполняться успешно, когда все работает и показывать ошибку если где-то что-то не так. Он должен тестировать только то, что задумывалось и кричать(зчк) сообщать если ожидаемый результат (expetced result) отличается от того, что мы получили при выполнении нашей программы. Но и из этого правила есть исключения.
К примеру, при написании когда, мы используем методологию TDD (Test Driven Development). В таком случае, только что написанные тесты никогда не выполнятся успешно, так как кода и функциональности, которую мы тестируем еще нет. Соответственно, если мы напишем n-е количество тестов, то наш билд нашего проекта всегда будет “failed”. Но при данном подходе это не должно мешать коммитить код в репозиторий и запускать все тесты автоматически на сервере CI. Вначале билд будет валиться, но с каждой реализованной фичей все больше тестов будет проходить успешно и ваш проект вскоре снова начнет собираться успешно.
Еще более интересная ситуация с тестами получается когда наше приложение использует сторонние библиотеки. Тут нам приходится работать с чужим кодом и/или со сторонней программой/API, исходников которой(го) у нас нет. Но тестировать-то надо. При этом у нас получаются интеграционные тесты, которые проверяют взаимодействие нашего кода с чужим.
В таком случае мы не можем контролировать работоспособность некоторых компонентов системы. Логично предположить, что тут тесты будут падать и это будет нормальным поведением. В большинстве случаев так и есть. Но бывают и другие ситуации:
Мы используем какой-то компонент SomeUsfulComponent, у которого должны быть две функции: FeatureA и FeatureB. И если хотя бы одна из них не работает, то тесты, которые проверяют взаимодействие нашей программы с этими функциями будут падать. А так как неработающие тесты на билд сервере - это поломанный билд, то дальше мы ничего делать уже не можем. Эта ситуация тоже вполне логичная. Вот только, например, мы в нашей программе можем обойтись без функции FeatureB. Как нам быть?
Тут, на мой взгляд, есть несколько решений данной проблемы. Привожу их в порядве “возрастания правильности”.