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

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

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

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

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

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

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

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