Достижение 100 % покрытия кода с помощью PHPUnit

Большая часть проблемы здесь заключается в настойчивом стремлении обеспечить 100 %-ное покрытие "строк". (Менеджерам нравится эта идея; это простая модель, которую они могут понять). Многие строки не являются "исполняемыми" (пробелы, пробелы между объявлениями функций, комментариями, объявлениями, "чистый синтаксис", например, закрытие "}" объявления коммутатора или класса или сложные операторы, разделенные на несколько исходных строк).

Что вы действительно хотите знать, так это "покрыт ли весь исполняемый код?" Это различие кажется глупым, но все же приводит к решению. XDebug отслеживает, что выполняется, ну, по номеру строки, и ваша схема на основе XDebug, таким образом, сообщает диапазоны выполненных строк. И вы получаете проблемы, обсуждаемые в этой теме, включая неуклюжие решения, связанные с необходимостью аннотировать код комментариями "не считай меня", помещением "}" в ту же строку, что и последний исполняемый оператор, и т.д. Ни один программист на самом деле не хочет этого делать, не говоря уже о том, чтобы поддерживать его.

Если определить исполняемый файл код как тот код, который может быть вызван или управляется условным (то, что компиляторы называют "базовыми блоками"), и отслеживание покрытия выполняется таким образом, тогда компоновка кода и глупые случаи просто исчезают. Инструмент тестового покрытия такого типа собирает так называемое "покрытие ветвей", и вы можете получить или не получить 100 % "покрытие ветвей" буквально, выполнив весь исполняемый код. Кроме того, он подберет те забавные случаи, когда у вас есть условное в течение строка (с использованием "x?y:z") или в которой у вас есть два обычных оператора в строке (например,

 if  (...)  {   if  (...)  stmt1; else stmt2; stmt3 }

Поскольку XDebug отслеживает по строкам, я полагаю, что он рассматривает это как одно утверждение и считает, что оно распространяется, если контроль попадает в строку, когда на самом деле нужно проверить 5 частей.

Наш Инструмент покрытия тестов PHP реализует эти идеи. В частности, он понимает, что код, следующий за оператором return, не является исполняемым, и он сообщит вам, что вы его не выполнили, если он не является пустым. Это делает первоначальную проблему операции просто исчезающей. Больше не нужно играть в игры, чтобы получить "реальные" номера покрытия.

Как и во всех вариантах выбора, иногда есть и обратная сторона. Наш инструмент имеет компонент code instrument, который работает только под Windows; инструментальный PHP-код может выполняться где угодно, а обработка/отображение выполняется независимой от платформы Java-программой. Так что это может быть неудобно для системы OSX OP. Инструментальный центр отлично работает в файловых системах с поддержкой NFS, поэтому он мог возможно, запустите инструментальный центр на ПК и запрограммируйте его файлы OSX.

Эта конкретная проблема была поднята кем-то, кто пытался увеличить свои номера покрытия; проблема была ИМХО искусственной и может быть устранена, обойдя искусственность. Есть еще один способ увеличить свои показатели без написания дополнительных тестов, и это поиск и удаление дубликатов кода. Если вы удалите дубликаты, будет меньше кода для тестирования, и тестирование одной (не) копии в эффектах проверяет (теперь несуществующую другую копировать), так что легче получить более высокие цифры. Вы можете прочитать больше об этом здесь.

Что касается вашей проблемы с покрытием кода оператора switch, просто добавьте случай "по умолчанию", который ничего не делает, и вы получите полное покрытие.

Вот что нужно сделать, чтобы получить 100% покрытие оператора switch:

Убедитесь, что существует хотя бы один тест, который отправляет несуществующий случай.

Итак, если у вас есть:

switch ($name) {
    case 'terry':
        return 'blah';
    case 'lucky':
        return 'blahblah';
    case 'gerard':
        return 'blahblah';
}

Убедитесь, что по крайней мере один из ваших тестов отправляет имя, которое не является ни terry, ни lucky, ни gerard.