Отдельные отчеты о покрытии кода для модульных и интеграционных тестов или один отчет для обоих?

Должен ли быть отдельный отчет о покрытии кода для модульных и интеграционных тестов или один отчет о покрытии кода для обоих?

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

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

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

Комбинированные показы покрытия вы , что код не охватываемые испытаний на всех , то есть является наиболее рискованным и нужно исследовать в первую очередь. Отдельные отчеты о покрытии здесь не помогут, так как они не позволяют вам узнать, тестируется ли код как-то еще или не тестируется вообще.

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

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

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

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

«Здесь есть пробел, но разработка модульного (интеграционного) теста для его покрытия была бы действительно громоздкой, каковы наши варианты? Давайте проверим комбинированное покрытие… о, это уже охватывалось в другом месте, то есть покрытие в нашем наборе не т критически важно. "

Вы не упоминаете свой инструмент тестирования. Во многих есть функции «объединения», которые позволяют объединять результаты нескольких прогонов или наборов. Если вам нужна сводная метрика покрытия, изучите функцию объединения в вашем инструменте покрытия.

Теперь мы можем поговорить о слоне в комнате?

Здесь нет ложки. И нет никакого «общего процента покрытия». По крайней мере, нет простого.

Процент охвата - это легко понятный показатель, представленный для того, чтобы помочь понять объем, глубину и диапазон комплектов тестирования. Но, как и любой простой тест, очень легко стать целью, зацикленной на этом значении, как своего рода волшебный талисман «полного тестирования».

Допустим, вы достигли славы «100% тестового покрытия». Ура! Но что это значит? 100% строк кода проверены, верно? Тогда как насчет этой строки?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

«Покрытие» этой строки означает что-то, но не много, потому что существует множество условий, которые есть Trueили Falseс некоторой вероятностью, но маловероятно, что вы проверили все комбинации этих условий. Даже если эта линия пройдена десяток раз, если одно из условий является относительно необычным, вы не приблизились к тестированию всех реальных результатов, которые могут произойти на практике. Чтобы сделать это более понятным, более синтетический пример:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

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

Я не говорю, что показатели охвата бесполезны. Они на самом деле великолепны . Они сосредоточены на одном из ключевых вопросов: насколько интенсивно тестируется моя программная система? Они помогают перейти от «у нас есть некоторые тесты» к «мы тщательно протестировали».

Но пока вы работаете над «комбинированными баллами», реальность такова, что ваш балл будет, как правило, за «покрытие заявления», а не «условие», «предикат» или «путь» . Таким образом, независимо от того, какое число дают вам ваши совокупные оценки, маловероятно, что оно даст вам истинную картину того, сколько из ваших потенциальных состояний программы и комбинаций состояний тестируется. Пока вы работаете над увеличением процента покрытия, рассмотрите возможность измерения предикатного покрытия. Это даст вам более реалистичный и почти всегда более отрезвляющий взгляд на объем тестов.