Какие методы вы на самом деле успешно использовали для улучшения покрытия кода?

Question

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

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

Answer 1

Удалить код.

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

Должен отметить, что это больше применимо для увеличения охвата старых баз кода по сравнению с новыми базами кода.

Answer 2

Я предполагаю, что вы читаете " Код покрыт против проверенного кода ", верно?

Как указано в этом вопросе,

Даже при 100% -ном блочном покрытии + 100% -ном покрытии дуги + 100% -ном безошибочном прямолинейном коде по крайней мере для одного пути все равно будут входные данные, которые выполняют пути / петли способами, которые демонстрируют больше ошибок.

Теперь я использую eclemma на основе EMMA, и этот инструмент покрытия кода объясняет, почему 100% код не всегда возможен: из-за частично покрытых линий из-за:

• Неявные ветви на одной строке.
• Код общего конструктора.
• Неявные ветви из-за блоков finally.
• Неявные ветви из-за скрытого Class.forName ().

Таким образом, все эти 4 случая могут быть хорошими кандидатами на рефакторинг, ведущий к лучшему охвату кода.

Теперь я согласен с ответом Фрэнка Крюгера. Некоторый непокрытый код может также указывать на необходимость проведения некоторого рефакторинга, включая некоторый код, который необходимо удалить;)

Answer 3

Две вещи, которые оказали наибольшее влияние на проекты, над которыми я работал, были:

1. Периодически «напоминать» команде разработчиков о необходимости реализации модульных тестов и проверять, как писать эффективные тесты.
2. Создание отчета об общем охвате тестированием и распространение его среди менеджеров по развитию.

Answer 4

Мы используем Perl, поэтому Devel :: Cover очень полезен для нас. Показывает покрытие для каждого оператора, покрытие филиала и условное покрытие во время модульного тестирования, а также такие вещи, как покрытие POD. Мы используем вывод HTML с легко распознаваемым зеленым цветом для «100%», через желтый и красный для более низких уровней покрытия.

РЕДАКТИРОВАТЬ: Чтобы немного расширить вещи:

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

Answer 5

FIT-тестирование улучшило покрытие кода. Это было здорово, потому что это совершенно другой курс.

Справочная информация: у нас есть смесь старого и нового кода. Мы стараемся проводить как можно больше модульного / интеграционного тестирования нового материала, но поскольку мы переходим на Hibernate / Postgres и от OODB, нет особого смысла тестировать устаревший код.

Для тех, кто не знает, FIT - это способ тестирования программного обеспечения с точки зрения пользователя. По сути, вы можете указать желаемое поведение в таблицах HTML: таблицы определяют действия с программным обеспечением и желаемые результаты. Наша команда пишет «клейкий код» (он же FIT-тест), который сопоставляет действия с вызовами кода. Обратите внимание, что эти тесты работают в режиме «из космоса» по сравнению с модульными тестами.

Используя этот подход, мы увеличили покрытие кода на несколько процентных пунктов. Дополнительным бонусом является то, что эти тесты будут соединяться между версиями: они будут тестировать унаследованный код, а затем - новый код. в каком-то смысле они служат регрессионными тестами.