Работа с дублированием между модульными и интеграционными тестами
У меня есть алгоритм, реализованный несколькими классами, и все они охвачены модульным тестом.
Я хотел бы провести его рефакторинг, который изменит поведение двух классов. Когда я меняю один класс и его тесты, все модульные тесты проходят, хотя алгоритм становится некорректным, пока не будет выполнен рефакторинг.
Этот пример иллюстрирует, что полного охвата модульными тестами иногда недостаточно, и мне нужны "интеграционные" тесты для всего алгоритма с точки зрения ввода-вывода. В идеале, такие тесты должны полностью покрывать поведение моего алгоритма.
Мой вопрос: похоже, добавляя такие интеграционные тесты, я делаю модульные тесты ненужными и лишними. Я не хочу поддерживать дублированную тестовую логику. Должен ли я удалить свои модульные тесты или оставить их как есть, например, для облегчения поиска ошибок?
1 ответ
Это является частью проблемы с тестами, которые слишком мелкозернистые и тесно связаны с реализацией.
Лично я написал бы тесты, которые фокусируются на поведении алгоритма и считают это "единицей". Тот факт, что он разбит на несколько классов, является деталью реализации, точно так же, как разбивка функциональности открытого метода на несколько более мелких частных методов также является деталью реализации. Я бы не писал тесты для приватных методов отдельно, они были бы проверены тестами функциональности публичного метода.
Если некоторые из этих классов в целом полезны и будут использоваться повторно в других местах, я бы подумал о написании для них модульных тестов, поскольку тогда они будут иметь определенное поведение самостоятельно.
Это может привести к некоторому дублированию, но это нормально, поскольку у этих классов теперь есть публичный контракт для поддержки (и который используется обоими компонентами, которые его используют), который могут определять эти тесты.
Интересно, см. Определение единицы в этой статье