Окремі звіти про покриття коду для одиничних та інтеграційних тестів, або один звіт для обох?

Чи повинен бути окремий звіт про покриття коду для одиничних та інтеграційних тестів або один звіт про покриття коду для обох?

Мислення за цим полягає в тому, що висвітлення коду дозволяє нам переконатися, що наш код був максимально охоплений тестами (наскільки це можливо машина зараз).

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

Перш за все, вам потрібно мати та проаналізувати комбіноване (загальне) покриття. Якщо ви думаєте про це, це найбільш природний спосіб правильно встановити пріоритетність своїх ризиків та зосередити свої зусилля на розробці тесту.

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

Окремий аналіз покриття також може бути корисним, але це краще зробити після того, як ви закінчите комбінований аналіз, і бажано, щоб він також включав результати аналізу комбінованого покриття.

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

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

З вищезгаданої точки зору, все ще бажано мати результати комбінованого аналізу покриття, щоб проаналізувати складніші випадки. Подумайте про це, завдяки цим результатам ваші рішення щодо розробки тесту можуть бути ефективнішими завдяки наявності інформації про набір тестів для партнерів.

"Тут є розрив, але розробка тесту на інтеграцію (інтеграція) була б справді громіздкою. Які наші варіанти? Давайте перевіримо комбіноване покриття ... о, воно вже охоплене в іншому місці, тобто, покриття його в нашому пакеті" t критично важливим ».

Ви не згадуєте свій інструмент для тестування. У багатьох є "комбінувати" функції, за допомогою яких можна зводити результати декількох циклів чи наборів. Якщо ви хочете отримати сукупний показник покриття, вивчіть функцію комбінування у вашому інструменті покриття.

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

Ложки немає. І немає "загального відсотка покриття". Принаймні, не простий.

Відсоток покриття - це легко зрозумілий показник, представлений для полегшення розуміння обсягу, глибини та діапазону тестових наборів. Але, як і будь-який простий орієнтир, дуже легко стати цільовим, закріпленим за цим значенням, як якийсь магічний талісман "повного тестування".

Скажімо, ви досягли слави "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

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

Я не кажу, що показники покриття марні. Вони насправді чудові . Вони зосереджуються на одному з ключових питань: Наскільки широко перевірена моя програмна система? Вони допомагають перейти від "у нас є кілька тестів" до "ми ретельно протестували".

Але поки ви працюєте над "комбінованими балами", реальність полягає в тому, що ваш результат, як правило, стосується "покриття звіту", а не покриття "умова", "предикат" або "шлях" . Тож незалежно від того, яке число дає ваші сукупні бали, малоймовірно, що воно дає вам справжнє уявлення про те, яка кількість потенційних станів вашої програми та комбінацій станів тестуються. Хоча ви працюєте над збільшенням відсоткового покриття, врахуйте також і вимірювання рівня покриття предикатами. Це дасть вам більш реалістичний - і майже незмінно більш тверезий - погляд на екстенсивність випробувань.