Даже если он не используется на практике, про него наверняка была какая-то задумка, как всё должно работать. И вот если поведение отличается от этой задумки, значит, он неправильный.
Даже если он не используется на практике, про него наверняка была какая-то задумка, как всё должно работать. И вот если поведение отличается от этой задумки, значит, он неправильный.
а вот правильность тестировать - это не про юниты и не про покрытие ) для этого куча других типов тестов есть
ну типа правильно ли складывается цифра с цифрой - да, правильно. а правильная ли цифра передается в рассчет калькулятора, где должны быть проценты, от 0 <> 100 - это уже не юниты
покрытие тебе покажет что у тебя есть две функции и обе работают корректно - одна продюсирует число, другая потребляет. другой вопрос - как они вместе работают
покрытие тебе покажет что у тебя есть две функции и обе работают корректно - одна продюсирует число, другая потребляет. другой вопрос - как они вместе работают
Покрытие не скажет, что переполнение вообще-то не обрабатывается. Ну и какой в нём толк?
Это само собой, но как же так, покрытие 100%, а код работает неправильно
давай по другому: юнит для функции funcA(x) юнит для функции funcB(x) и интеграционник для funcA(x)+funcB(x) = y юнитами ты покроешь все ветвления внутри funcA/funcB и это будет корректно, т.к. написаный код это тестирует. покрытие кода у тебя 100%. интеграционник тебе покроет что результат интеграции двух функций выдает правильный результат по бизнесу. тут "покрытие" это "покрытие бизнес-логики" а не "кода"
Человек пишет код, обрабатывающий некоторое множество ситуаций, потом пишет тест на все эти ситуации с покрытием 100%. А потом оказывается, что он про многие другие ситуации не подумал.