Есть ли способ измерить покрытие кода с помощью DUnit? Или есть ли какие-либо бесплатные инструменты для этого? Что вы используете для этого? Какое покрытие кода вы обычно используете?
Джим МакКит: Спасибо за подробный ответ. Я говорю об модульном тестировании в смысле подхода TDD, а не только о модульных тестах после возникновения сбоя. Меня интересует охват кода, который я могу достичь с помощью некоторых базовых предписанных модульных тестов.
Я только что создал новый проект с открытым исходным кодом в Google Code с базовым инструментом покрытия кода для Delphi 2010. https://sourceforge.net/projects/delphicodecoverage/ p >
Сейчас он может измерять охват линии, но я планирую добавить класс и покрытие методов.
Он генерирует html-отчеты с суммарным, а также помеченным источником, показывающим, какие линии покрыты (зеленые), а не (красные) и остальные строки, у которых не было никакого кода, созданного для них.
Update: Начиная с версии 0.3 Delphi Code Coverage вы можете создавать XML-отчеты, совместимые с плагином Hudson EMMA, для отображения трендов покрытия кода внутри Hudson.
Update: Версия 0.5 содержит исправления ошибок, повышенную конфигурацию и очистку отчетов
Update: Версия 1.0 обеспечивает поддержку для выпуска emma, охвата классов и методов и охвата библиотек DLL и BPL
Я не знаю никаких бесплатных инструментов. AQTime - это почти стандарт defacto для профилирования Delphi. Я не использовал его, но был найден быстрый поиск Discover for Delphi, который теперь является открытым исходным кодом, но просто охватывает код.
Любой из этих инструментов должен дать вам представление о том, сколько кодов покрывает ваши юнит-тесты.
Вы имеете в виду покрытие кода от модульных тестов или устаревшего кода? Вообще, я думаю, что только тестируемый код, который имеет сбой, должен быть покрыт unit test (да, я понимаю, что может начаться священная война, но вот где я стою). Так что это будет довольно низкий процент.
Теперь устаревший код, с другой стороны, - это другая история. Код устаревания - это код, который не используется. Вам, скорее всего, не нужен инструмент, чтобы рассказать вам об этом для большого количества вашего кода, просто найдите маленькие синие точки после компиляции в Delphi. Все, что без синей точки, устарело. Как правило, если код не используется, его следует удалить. Таким образом, это будет 100% охват кода.
Существуют и другие сценарии для устаревшего кода, например, если у вас есть специальный код для обработки, если дата когда-либо наступает 31-го февраля. Компилятор не знает, что этого не может быть, поэтому он компилирует его и дает ему синюю точку. Теперь вы можете написать unit test для этого и протестировать его, и это может сработать, но тогда вы просто потратили свое время во второй раз (сначала для написания кода, второй для его тестирования).
Есть инструменты для отслеживания того, какие пути кода используются при запуске программы, но это только аналогично, так как не все пути кода будут использоваться каждый раз. Подобно этому специальному коду, который вы должны обрабатывать високосный год, он будет запускаться только каждые четыре года. Поэтому, если вы выберете его, ваша программа будет разбита каждые четыре года.
Наверное, я действительно не ответил на ваш вопрос о DUnit и Code Coverage, но я думаю, что, возможно, у вас остались другие вопросы, с которых вы начали. Какое покрытие кода вы ищете?
ОБНОВЛЕНИЕ: Если вы используете подход TDD, тогда код не записывается до тех пор, пока вы не напишете для него тест, поэтому по своей природе у вас есть 100 тестовых покрытий. Конечно, только потому, что каждый метод осуществляется с помощью теста, не означает, что его весь диапазон поведения осуществляется. SmartInspect предоставляет очень простой способ измерения методов, которые вызывают вместе с синхронизацией и т.д. Это немного меньше, чем AQTime, но не бесплатно, С некоторой дополнительной работой с вашей стороны вы можете добавить инструменты для измерения каждого кода (ветки операторов "if" и т.д.). Конечно, вы также можете просто добавить свой собственный журнал в свои методы для получения отчета о покрытии, и это бесплатно (хорошо, ожидайте своего времени, что, вероятно, стоит больше, чем инструменты). Если вы используете JEDI Debug, вы также можете получить стек вызовов.
TDD действительно не может быть легко применен ретроактивно к существующему коду без большого количества рефакторинга. Хотя новые IDE Delphi имеют возможность генерировать unit test заглушки для каждого публичного метода, который затем дает вам 100% -ный охват ваших общедоступных методов. То, что вы помещаете в эти заглушки, определяет, насколько эффективно это покрытие.
Я использую Discover for Delphi, и он выполняет эту работу, для модульного тестирования с использованием DUnit и функционального тестирования с помощью TestComplete.
Обнаружение можно настроить для запуска из командной строки для автоматизации. Как в:
Discover.exe Project.dpr -s -c -m
Откройте для меня великолепные работы. Это вряд ли замедляет ваше приложение, в отличие от AQTime. Конечно, это не проблема для вас. Я думаю, что последние версии AQTime лучше работают в этом отношении.
Я использую Discover "в течение многих лет, отлично работал с BDS2006 (включая последнюю версию XE * Delphi, которую я использовал и до сих пор использую), но ее текущее состояние с открытым доступом, неясно, как сделать он работает с версиями Delphi XE *. Позор действительно, потому что мне понравился этот инструмент, быстрый и удобный практически во всех отношениях. Итак, теперь я перехожу к delphi-code-coverage...