Здравствуйте, fddima, Вы писали:

F> Update: Кстати, есть один немаловажный момент, — если система (программный комплекс) предполагает долгую жизнь, то интеграционные тесты (в случае их хорошего исполнения) позволяют полностью абстрагироваться от конкретной базы кода (понятно, что если это позволяет предмет, и в необходимых количествах), что сыграет наруку в будущем.
Интеграционные и юнит-тесты друг-друга не заменяют. Оба вида нужны и важны.
У меня был опыт в образцово-показательном проекте где было то, и то.
Юнит-тестов было несколько десятков тысяч, выполнялись они за 1-3 минуты на машине разработчика, поэтому перед коммитом они прогонялись всегда. Большее число багов отлавливалось именно ЮТ.
Интеграционных было около тысячи. Выполнялись они около 20 минут, обычно разработчики их запускали выборочно, лихорадочно правя если что-то поломалось в CI.
Ещё были функциональные тесты (которые ты называешь интеграционными), абстрагированые от базы кода, т.е. взаимодействуют с системой по тем же каналам, что и реальные клиенты — WebUI, REST, FIX, sockets, etc. Вот их было около восьми тысяч и выполнялись они около 20 минут на кластере из ~150 машин. Выполнить все на машине разработчика — нереально. Поэтому без предварительного багофильтра в виде ЮТ и ИТ они бы вечно были красными и бесполезными. А так падение ФТ в CI было событием, если в течение 5 минут поправить ошибку не можешь, твой коммит ревертят.