Code coverage report - инструмент для изучения покрытия кода тестами, предоставляемый фреймворком phpUnit 3.x. phpUnit умеет предоставлять отчет в множестве форматов, таких как xml, html, и даже складывать полученные данные в БД. Таким образом эту информацию можно обрабатывать собственными силами или передавать в различные средства визуализации для построения графиков.
Инструмент, которым можно воспользоваться, что называется, из коробки - html-отчет о покрытии кода. Данные в отчете сгруппированы в дерево, повторяющее файловую систему, и рядом с каждым файлом и папкой указывается процент покрытия. Кроме цифр, показывающих процент протестированного кода, в отчете по файлу выводится полный листинг, где зеленым помечаются строки, которые вызывались в процессе выполнения теста, и красным ни разу не выполнявшиеся. Рядом с выполненными строками также указывается число вызовов. Такое представление данных черезвычайно удобно. С его помощью отлично видно, какие ветки условных операторов не выполнялись и какие дополнительные проверки можно встроить в тест.
Однако, в моем случае использование code coverage report омрачилось тем, что в процесс генерации отчета постоянно прерывался ошибкой превышения допустимой памяти. Использование свежей версии 3.3, накатывание патчей, оптимизирующих работу phpUnit с памятью проблему не решили. После трассировки с выводом memory_usage проблему удалось локализовать: при построении отчета по конкретному файлу, phpUnit генерирует html-код прямо в памяти, после чего записывает весь файл целиком, а в проекте, отчет для которого я хотел построить, оказалось несколько файлов с 5-10 тысячами строк (конфигурация, константы и пр.).
Решение подсказал сам код phpUnit. Если внимательно посмотреть на первые инструкции php-файлов, можно увидеть строки:
PHPUnit_Util_Filter::addFileToFilter(__FILE__, 'PHPUNIT');
Эта инструкция добавляет файл в блек-лист, и при построении code coverage report этот файл пропускается. Первый аргумент функции - имя файла, второй - группа в блек-листе и может быть опущен.
Аналогичная инструкция имеется и для целых папок:
PHPUnit_Util_Filter::public static function addDirectoryToFilter($directory, $suffix = '.php', $group = 'DEFAULT')
Назначение ее аргументов, мне кажется понятно из их названия.
К сожалению, имеется еще небольшая проблема - скорость генерации отчета. Генерация отчета для проекта с > 30 тысяч строк с вызовом ~300 тестов заняла 6 минут (сами тесты без отчета выполняются за ~3 секунды).
В версии 3.3 разработчики phpUnit обещают произвести оптимизацию скорости. Будем ждать.
Оставить комментарий