Дисклеймер раз. Кликбейтность заголовка - не постановка диагнозов, а провокация дискуссии. Дисклеймер два. Все нижесказанное не касается TDD и прочего test-first. Разговор о том, когда тесты пишутся после.

Пишу на Джаве за деньги четвертый год. Последние полтора года имею дело с «покрытием юнит-тестами». Как правило это что-то типа 80% покрытия, юнит - публичный метод класса. И чем дальше имею с этим дело, тем больше закрадывается подозрение, что подобное покрытие юнит-тестами - напрасная трата времени. Главная причина - хрупкость этих самых тестов. Я буквально могу перечислить по пальцам одной руки случаи, когда тесты краснели из-за пойманных ошибок. В 99% случаев это происходит потому, что в процессе изменений продуктового кода меняются интерфейсы юнитов (сигнатуры методов). И тесты приходится поддерживать, поддерживать и поддерживать. Чтобы если повезет, когда-нибудь увидеть действительно полезный не прошедший тест.

Есть точка зрения, что юнитом в юнит-тестировании должен быть не отдельный метод, а некая логическая единица работы, часто она будет включать в себя несколько методов и даже классов. Но и тут есть определенные нюансы. Количество моков (моки ведь популярны сегодня?) в таких тестах может быть не самыми приятными.

Складывается ощущение, что «code coverage» с развитием CI/CD стал вездесущ и очень часто от него попахивает карго-культом. При этом я не отрицаю пользу юнит-тестов как таковых. Считаю их полезными, когда юнит устойчив и содержит в себе некую ключевую логику, которую действительно имеет смысл тестировать атомарно.

Что скажете?

Может кто видел что из open-source? А то на конференциях и собеседованиях все красиво говорят, а как реальный проект откроешь - тушите свет.