давай по другому: юнит для функции funcA(x) юнит для функции funcB(x) и интеграционник для funcA(x)+funcB(x) = y юнитами ты покроешь все ветвления внутри funcA/funcB и это будет корректно, т.к. написаный код это тестирует. покрытие кода у тебя 100%. интеграционник тебе покроет что результат интеграции двух функций выдает правильный результат по бизнесу. тут "покрытие" это "покрытие бизнес-логики" а не "кода"
f(x) + g(y) = z - это уже код, для которого надо писать интеграционный тест?
вопрос был "как измерить качество кода" - покрытием
Так в том-то и дело, что это покрытие тебе ничего не гарантирует. Не говоря о том, что покрытие - это характеристика тестов, а не самого тестируемого кода. Выкинь тесты, и качество кода не изменится.
Так в том-то и дело, что это покрытие тебе ничего не гарантирует. Не говоря о том, что покрытие - это характеристика тестов, а не самого тестируемого кода. Выкинь тесты, и качество кода не изменится.
не пиши юниты, пиши интеграционники. потонешь в болоте говнокода, который будет выполнять свою функцию. функциональность продукта о качестве кода не говорит ничего.
не пиши юниты, пиши интеграционники. потонешь в болоте говнокода, который будет выполнять свою функцию. функциональность продукта о качестве кода не говорит ничего.
Ты ответь на вопрос: после вырезания тестов из проекта код тут же становится некачественным, да?