Мы знаем, что покрытие кода - это плохая метрика, используемая при измерении качества тестового кода. Мы также знаем, что тестирование языка/рамки - пустая трата времени.
С другой стороны, какие показатели мы можем использовать для определения тестов качества? Есть ли какие-либо лучшие практики или эмпирические правила, которые вы узнали, чтобы помочь вам идентифицировать и писать тесты более высокого качества?
Удостоверьтесь, что это легко и быстро писать тесты. Затем напишите их много.
Я обнаружил, что очень сложно заранее предсказать, какие тесты будут те, которые в конечном итоге потерпят неудачу или сейчас, или длинный путь вниз по линии. Я, как правило, применяю подход с рассеивателем, пытаясь поразить угловые случаи, если я могу думать о них.
Кроме того, не бойтесь писать большие тесты, которые проверяют кучу вещей вместе. Конечно, если этот тест терпит неудачу, может потребоваться больше времени, чтобы выяснить, что пошло не так, но часто проблемы возникают только после того, как вы начнете склеивать вещи.
пишите тесты, которые проверяют базовую функциональность и индивидуальные варианты использования программного обеспечения. Затем напишите тесты, чтобы проверить случаи краев и проверить ожидаемые исключения.
Другими словами, напишите хорошие модульные тесты с точки зрения клиента и забудьте о показателях для тестового кода. никакие показатели не скажут вам, является ли ваш тестовый код хорошим, только функциональное программное обеспечение сообщает вам, когда ваш тестовый код хорош.
Я думаю, что пример использования очень полезен, чтобы получить лучшее тестовое покрытие. Если у вас есть свои функциональные возможности с точки зрения использования, он легко преобразуется в различные тестовые сценарии, чтобы покрыть положительные, отрицательные и исключения. В прецеденте также указываются предварительные условия и подготовка данных, если таковые имеются, что очень удобно при написании тестовых случаев.
Мои эмпирические правила:
Я бы не согласился с тем, что охват кода не является полезным показателем. Если у вас нет покрытия 100% кода, это, по крайней мере, указывает области, которые нуждаются в большем количестве тестов.
В общем, хотя, как только вы получите адекватное покрытие заявлений, следующим логическим местом для перехода является письменный тест, который либо предназначен для прямой проверки требований, которые код был написан для удовлетворения, либо для того, чтобы подчеркнуть край -cases. Ни один из них не упадет естественным образом из всего, что вы можете легко измерить напрямую.
Есть два хороших способа проверить качество теста
С просмотром кода можно проверить шаги импортщиков, определенные @Patrick Cuff в его ответе fooobar.com/info/70174/...
Обзор кода - это систематическое обследование (часто называемое экспертной оценкой) исходного кода компьютера. Он предназначен для поиска и устранения ошибок, забытых на начальной стадии разработки, улучшения как общего качества программного обеспечения, так и навыков разработчиков.
Во-вторых, это дешевле - это автоматизированное задание, измеряющее качество теста.
Тестирование мутаций (или анализ мутаций или мутация программы) используется для разработки новых тестов программного обеспечения и оценки качества существующих тестов программного обеспечения.
Связанные вопросы