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

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

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

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

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

— Даниэль Каплан
источник

Ответы:

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

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

— Грег Хьюгилл
источник

+1 за рекомендацию автоматизировать тесты, поскольку это приводит к очевидному вопросу: «Зачем убивать автоматизированный тест?»

Да, я согласен с этим. Конечно, даже если вы не достаточно хорошо охвачены модульным тестом, это может вас даже укусить. Например, в настоящее время у нас есть набор интеграционных тестов, который занимает около 6 часов ... но я не думаю, что тест был КОГДА-ЛИБО удален из-за ориентации моей компании на совместимость

— Earlz

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

— Даниэль Каплан

@tieTYT: Да, это звучит как хорошая идея. Модульные тесты хороши; Модульные тесты для вещей, которые вы знаете, уже сломались, еще лучше.

— Грег Хьюгилл

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

— Ryathal
источник

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

— Даниэль Каплан

@tieTYT: тестирование чего-либо через пользовательский интерфейс часто приводит к очень нестабильному решению. Тем не менее, тестирование с помощью пользовательского интерфейса важно, но иногда бывает, что ручные тесты производят меньше усилий, чем попытки автоматизировать этот тест и поддерживать его стабильность. Поэтому, если вы считаете, что это именно тот случай, вы можете удалить этот «интеграционный тест» из списка автоматизированных тестов и добавить его в свой план тестирования ручных тестов.

— Док Браун

@DanielKaplan можно ли обновить интеграционный тест, чтобы он был более стабильным? Если происходит сбой из-за того, что html иногда изменяется, то возможно протестируйте что-то вроде «имя пользователя появляется на странице после входа в систему», а не что-то более конкретное, например «имя пользователя появляется в этом div после входа в систему»

— Jen