Как вы оцениваете качество ваших юнит-тестов?

Question

Если вы (или ваша организация) стремитесь провести тщательное модульное тестирование своего кода, как вы оцениваете успех или качество ваших усилий?

• Используете ли вы покрытие кода, на какой процент вы рассчитываете?
• Считаете ли вы, что такие философии, как TDD, оказывают большее влияние, чем метрики?

Answer 1

Концепция мутационного тестирования выглядит многообещающе как способ измерения (тестирования?) Качества ваших юнит-тестов. Мутационное тестирование в основном означает создание небольших «мутаций» в вашем производственном коде, а затем проверка, не прошел ли какой-либо модульный тест. Маленькие мутации обычно означают изменение and на or или < на <=. Если один или несколько юнит-тестов не пройдены, это означает, что «мутант» был пойман. Если мутант выжил в вашем наборе юнит-тестов, это значит, что вы пропустили тест. Когда я применяю мутационное тестирование к коду со 100% охватом линий и ветвей, он обычно находит несколько мест, где я пропустил тесты.

См. https://en.wikipedia.org/wiki/Mutation_testing для описания концепции и ссылок на инструменты.

Answer 2

Дополнительная техника, которую я пытаюсь использовать, состоит в том, чтобы разбить ваш код на две части. Я недавно писал об этом здесь . Краткое описание состоит в том, чтобы поддерживать ваш производственный код в двух наборах библиотек, где один набор (возможно, больший набор) имеет 100% -ное покрытие строк (или лучше, если вы можете измерить его), а другой набор (надеюсь, небольшое количество кода) 0% покрытия, да ноль процентов покрытия.

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

Answer 3

• В дополнение к TDD, я обнаружил, что со времен BDD я пишу более вменяемые тесты (например, http://rspec.info/)
• Вечная дискуссия - это всегда издеваться или не издеваться. Некоторые макеты могут стать более сложными, чем код, который они тестируют (что обычно указывает на плохое разделение проблем).
  • Поэтому мне нравится идея иметь такую ​​метрику: сложность теста по сложности кода. или упрощенно: количество тестовых строк на строки кода.