Почему я не пищу unit тесты
Как обычно, нашел статью, которая в явном виде формулирует мои ощущения по поводу unit vs сквозных (end to end/интеграционных) тестов
Unit Test Fetish
Вкратце:
- единственный сквозной тест покрывает больше функциональности, чем десятки юнит тестов. Более того, сквозной тест покрывает именно то что нужно - критический путь, самый типичный вариант использования вашего софта. Сквозной тест гарантирует, что ваш код работает в самом общем случае. Юнит тест не гарантирует ничего.
- Юнит тесты ведут к замораживанию архитектуры. Любое изменение внутренней структуры модуля и/или их взаимодействия требует переписывания юнит тестов, что ведет к удвоению работы.
- Юнит тесты позволяют легко измерять покрытие кода тестами, что ведет в к понятному желанию добиваться 100% покрытия, вместо написания собственно полезного кода. Совсем плохо становится, если процентом покрытия начинает озабочиваться менеджмент.
Надо сказать, что за последние 4 года я не выпустил в продакшн ни одного проекта без тестов. При этом unit тестов в них нет почти совсем.
Единственный случай, когда unit тесты действительно нужны - если ваш модуль реализует какой-то нетривиальный алгоритм, который вы не можете уложить в голове за один раз и не уверены в его реализации. Но честно говоря, часто ли такое встречается в ваших проектах? Подавляющее большинство модулей почти в любом проекте абсолютно тривиальны, все сложности и ошибки возникают на стыках модулей а не внутри.
Unit Test Fetish
Вкратце:
- единственный сквозной тест покрывает больше функциональности, чем десятки юнит тестов. Более того, сквозной тест покрывает именно то что нужно - критический путь, самый типичный вариант использования вашего софта. Сквозной тест гарантирует, что ваш код работает в самом общем случае. Юнит тест не гарантирует ничего.
- Юнит тесты ведут к замораживанию архитектуры. Любое изменение внутренней структуры модуля и/или их взаимодействия требует переписывания юнит тестов, что ведет к удвоению работы.
- Юнит тесты позволяют легко измерять покрытие кода тестами, что ведет в к понятному желанию добиваться 100% покрытия, вместо написания собственно полезного кода. Совсем плохо становится, если процентом покрытия начинает озабочиваться менеджмент.
Надо сказать, что за последние 4 года я не выпустил в продакшн ни одного проекта без тестов. При этом unit тестов в них нет почти совсем.
Единственный случай, когда unit тесты действительно нужны - если ваш модуль реализует какой-то нетривиальный алгоритм, который вы не можете уложить в голове за один раз и не уверены в его реализации. Но честно говоря, часто ли такое встречается в ваших проектах? Подавляющее большинство модулей почти в любом проекте абсолютно тривиальны, все сложности и ошибки возникают на стыках модулей а не внутри.