На самом деле нет никакого способа убедиться, что ваши тестовые примеры правильны, кроме как при действительно хорошей концентрации при их создании - понимании требований, понимании кода и уверенности в том, что они согласны. Смысл иметь набор тестов является то , что вам нужно только сделать это один раз, и с тех пор вы можете просто повторно выполнить тесты и проверить , что они проходят, в то время как без набора тестов вы должны сосредоточиться очень трудно все время , то есть всякий раз, когда вы делаете что-нибудь со своей базой кода. Но фундаментальная проблема, связанная с необходимостью убедиться, что вы поступили правильно, в первую очередь остается - компьютеры просто недостаточно умны, чтобы избавить нас от этой задачи.
Следовательно, (1) если ваш набор тестов неполон, не существует простого способа увидеть это. Анализ покрытия кода может доказать, что некоторые строки кода никогда не выполняются, т. Е. Что набор в некотором роде несовершенен, но не насколько серьезен этот недостаток, и он никогда не сможет доказать, что этого достаточно. Даже при 100% покрытии кода у вас нет гарантии, что все соответствующие штатыэтой системы, и для любой реалистической системы полный охват состояния невозможен из-за комбинаторного числа состояний, которые могут существовать. Один хороший способ убедиться в том, что ваш тестовый пример является по меньшей мере правильным для проверки того, что вы хотите проверить, - это написать тест, убедиться, что он действительно провалился, написать / изменить код, а затем убедиться, что он сейчас проходит. Отсюда и энтузиазм разработки, основанной на тестировании: она позволяет вам быть совершенно уверенным, что отдельный тест делает правильные вещи, и если вы создадите всю свою базу кода таким образом, вы сможете получить аналогичный уровень доверия даже в большой системе.
(2) Набор тестов, как правило, становится недостаточным при изменении требований - вам не нужно догадываться. Если клиент хочет, чтобы какое-то конкретное поведение было изменено, и ваши тесты были бы успешными как до, так и после изменения, то, очевидно, они не использовали это конкретное отношение ввода / вывода.
Что касается устаревших систем, в которых нет тестового покрытия или если вы не знаете, что такое покрытие, то формальных доказательств нет, но (если исходить из родительского мнения: личное мнение следует!), Исходя из опыта, в подавляющем большинстве случаев вероятность того, что тесты являются не адекватными. Когда тестирование рассматривается как постфактум, необязательное, повышающее качество, но не очень необходимое действие, оно имеет тенденцию быть неполным и бессистемным, потому что стимул для того, чтобы убедиться, что тесты идут в ногу с базой кода, просто отсутствует. не там.