Как люди поддерживают свой набор тестов?

В частности, мне интересно узнать о следующих аспектах:

1. Откуда вы знаете, что ваши тесты неверны (или устарели) и нуждаются в ремонте (или выброшены)? Я имею в виду, что даже если контрольный пример стал недействительным, он все равно может пройти и оставаться безмолвным, что может дать вам ложную уверенность в том, что ваше программное обеспечение работает нормально. Итак, как вы понимаете такие проблемы вашего набора тестов?

2. Откуда вы знаете, что ваш набор тестов больше не является достаточным и что следует добавить новые тестовые примеры? Я предполагаю, что это как-то связано с изменениями требований, но существует ли системный подход для проверки адекватности набора тестов?

Краткий ответ: используйте известные инструменты, которые помогают поддерживать качество тестовых случаев, такие как следующие инструменты покрытия кода и качества кода: Cobertura, PMD, Sonar и т. Д., Которые помогут вам заметить, когда критический компонент программы недостаточно протестирован. Кроме того, пишите интеграционные тесты, которые, скорее всего, сломаются первыми, если что-то пойдет не так.

Длинный ответ:

Откуда вы знаете, что ваши тесты неверны (или устарели) и нуждаются в ремонте (или выброшены)? Я имею в виду, что даже если контрольный пример стал недействительным, он все равно может пройти и оставаться безмолвным, что может дать вам ложную уверенность в том, что ваше программное обеспечение работает нормально. Итак, как вы понимаете такие проблемы вашего набора тестов?

• Используя инструменты покрытия кода, такие как Cobertura , вы можете обнаружить, что тестовых случаев для данного класса или сложных методов больше не достаточно. Вам не нужно достигать 100% покрытия кода везде, и в большинстве случаев это будет трудно достичь и не обязательно будет полезно; но тесты для наиболее важных аспектов программы должны поддерживаться с целью не менее 80% покрытия кода.
• Используя инструменты непрерывной сборки и интеграции , такие как Jenkins, которые мне очень нравятся, в сочетании с плагином Sonar вы можете устанавливать триггеры, которые отправляют электронные письма и другие типы предупреждений лицам, ответственным за последние изменения. Различные графики и статистика (Sonar также использует Cobertura среди многих других инструментов) помогают рецензентам кода и разработчикам тестовых примеров сосредоточиться на том, что важно.

Откуда вы знаете, что ваш набор тестов больше не является достаточным и что следует добавить новые тестовые примеры? Я предполагаю, что это как-то связано с изменениями требований, но существует ли системный подход для проверки адекватности набора тестов?

То, что я написал для первого вопроса, является частью ответа на ваш второй вопрос. Я также добавлю следующие пункты здесь:

• Напишите интеграционные тесты (или «бизнес», если хотите) в дополнение к тестам. Скорее всего, они сначала изменятся / сломаются, потому что они часто зависят от нескольких классов / методов. И так как они часто ломаются, менее вероятно, что они будут забыты. Единственный подход / методология, которая, исходя из моего личного опыта, помогает в написании хороших тестов, - это разработка через тестирование . Особенно, если человек, пишущий контрольный пример, НЕ является тем же человеком, который пишет код для него. Написание хороших тестовых примеров с использованием TDD также требует времени, но результаты, по крайней мере для меня, были чрезвычайно удовлетворительными.
• Всякий раз, когда появляется ошибка, напишите исправление и контрольный пример, который идет с ним. Тестовый случай должен охватывать только эту конкретную ошибку. Поскольку вы полностью рассмотрели код, ответственный за ошибку, она больше не должна появляться.

На самом деле нет никакого способа убедиться, что ваши тестовые примеры правильны, кроме как при действительно хорошей концентрации при их создании - понимании требований, понимании кода и уверенности в том, что они согласны. Смысл иметь набор тестов является то , что вам нужно только сделать это один раз, и с тех пор вы можете просто повторно выполнить тесты и проверить , что они проходят, в то время как без набора тестов вы должны сосредоточиться очень трудно все время , то есть всякий раз, когда вы делаете что-нибудь со своей базой кода. Но фундаментальная проблема, связанная с необходимостью убедиться, что вы поступили правильно, в первую очередь остается - компьютеры просто недостаточно умны, чтобы избавить нас от этой задачи.

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

(2) Набор тестов, как правило, становится недостаточным при изменении требований - вам не нужно догадываться. Если клиент хочет, чтобы какое-то конкретное поведение было изменено, и ваши тесты были бы успешными как до, так и после изменения, то, очевидно, они не использовали это конкретное отношение ввода / вывода.

Что касается устаревших систем, в которых нет тестового покрытия или если вы не знаете, что такое покрытие, то формальных доказательств нет, но (если исходить из родительского мнения: личное мнение следует!), Исходя из опыта, в подавляющем большинстве случаев вероятность того, что тесты являются не адекватными. Когда тестирование рассматривается как постфактум, необязательное, повышающее качество, но не очень необходимое действие, оно имеет тенденцию быть неполным и бессистемным, потому что стимул для того, чтобы убедиться, что тесты идут в ногу с базой кода, просто отсутствует. не там.