Чи слід виключати код для аналізу покриття коду?

Я працюю над декількома додатками, в основному застарілими. Наразі їх охоплення кодом досить низьке: загалом від 10 до 50%.

Протягом декількох тижнів ми регулярно обговорюємо з командами Бангалор (основна частина розробки проводиться в офшорному напрямку в Індії) щодо виключення пакетів або класів для Cobertura (наш інструмент покриття коду, навіть якщо ми зараз переходимо на JaCoCo).

Їх точка зору полягає в наступному: оскільки вони не пишуть одиничні тести на деяких шарах програми (1) , ці шари повинні бути просто виключені з міри покриття кодом. Іншими словами, вони хочуть обмежити міру покриття коду кодом, який тестується або повинен бути протестований .

Крім того, коли вони працюють над тестовою одиницею для складного класу, переваги - суто з точки зору покриття коду - будуть непоміченими завдяки великому застосуванню. Зменшення обсягу покриття коду зробить подібні зусилля більш помітними ...

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

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

Крім того, ми не зможемо точно знати, що розглядається в мірі покриття коду. Наприклад, якщо у мене є 10 000 рядків програми коду з покриттям коду 40%, я можу вирахувати, що 40% моєї бази коду перевірено (2) . Але що станеться, якщо ми встановимо виключення? Якщо покриття коду зараз становить 60%, що я можу точно вирахувати? Що 60% моєї "важливої" кодової бази перевірено? Як я можу

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

Яка ваша думка з цього приводу? Як ви робите свої проекти?

Спасибі.

(1) Ці шари, як правило, відносяться до бобів UI / Java тощо.

(2) Я знаю, що це неправда. Насправді це означає лише, що 40% моєї кодової бази

Я, як правило, виключаю автоматично генерований код, наприклад клієнти WCF, які створює Visual Studio. Зазвичай там багато рядків коду, і ми їх ніколи не збираємось перевіряти. Це робить дуже деморалізуючим збільшення тестування на великому шматку коду в інших місцях і лише збільшити охоплення коду на 0,1%.

Я також виключаю взаємодії на рівні даних, доки команда може з упевненістю сказати, що цей шар такий тонкий, наскільки це можливо. Хоча ви можете стверджувати, що, якщо шар тонкий, він не матиме масивного ефекту, він залишає безліч компонентів у звіті про покриття 0% проти них, тому ми не обов'язково помічаємо ті, які нам потрібні по-справжньому хвилюватися. Шар інтерфейсу може бути аргументований аналогічним чином, залежно від використовуваної рамки.

Але, як зустрічний момент, я також виключаю самі одиничні тести. Вони завжди повинні мати ~ 100% покриття, і вони становлять великий відсоток бази коду, перекосуючи фігури небезпечно вгору.

Гарне питання. Як правило, я схильний виключати код із покриття коду з якихось причин, наприклад, це:

• згенеровано
• спадщина (більше не оновлюється)
• ось це: певні шари, я не збираюся тестувати

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

АЛЕ:

1. У вас має бути вагома причина, чому взагалі виключати певний шар із тестування підрозділів (можуть бути питання - від вашого начальника, ваших товаришів по команді, преси ;-)
2. Якщо ви хочете, щоб вони перевірили ці шари, вам слід включити їх до статистики, щоб кожен день показувати всій команді, що це важливо і що потрібно робити.

Нарешті: не сприймайте цифри занадто серйозно. 30% покриття може підтверджувати, що програмне забезпечення є суцільним, коли це є найважливішою його частиною.

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

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

Зараз я не дуже добре знайомий з інструментами покриття коду, якими ви користуєтесь, або я не знайомий з квасолею Java, але з того, що ви говорите, вони пов'язані з інтерфейсом користувача.

Маючи свої обмежені знання, я маю це сказати:

1. Не дозволяйте числам будь-якого виду засобів тестування перешкоджати вашим тестам.
2. Якщо класи складні і не перевіряються на одиниці, завжди добре перерозподілити їх на більш компактні та перевірені класи. Це вимагатиме багато зусиль і відданості, але це заплатить в перспективі.
3. Тестування компонентів інтерфейсу може бути важким, але ви все одно можете перевірити функцію, яку виконують ці компоненти.
4. Якщо ви робите веб-проект, ви можете використовувати QUnit, щоб перевірити весь код клієнтської сторони.

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

Деякі виключення мають сенс (код пластини котла, який не має реального впливу або потенційного впливу на правильне функціонування вашого проекту). Навіть збір покриття коду як метрики є безглуздим, оскільки він все одно не говорить вам про корисне. 100-відсоткове покриття коду не є реальною метою, і низький показник покриття також не може бути поганим залежно від проекту, можливо, 20-30% покриття коду охоплює все, що варто перевірити. Покриття кодом говорить лише про те, що X% вашого коду, який потенційно варто покрити, - це тест невідомої якості.

Я пропоную повідомити про набір показників для кожного шару вашого коду. Ці показники повинні включати інформацію про розмір (наприклад, LoC, кількість бібліотек, кількість класів або методів тощо), інформацію про тестування (наприклад, охоплення) та інформацію про помилки (наприклад, пошук та виправлення частот).

Ваші виключені шари матимуть 0% покриття, а ваші тестовані області матимуть 60% покриття, яке ви згадали. Інформація про розмір дозволить зрозуміти, скільки коштує не перевірена або перевірена. Інформація про помилку повідомить вас про те, чи можливо ви створюєте тести для виключених шарів і чи працюють ваші існуючі тести.

Програмним організаціям легко стати занадто зосередженими на чистоті показників. Ми не робимо метрик, ми робимо гарне програмне забезпечення. Показник, який допомагає вам своєчасно доставляти якісне програмне забезпечення - це найчесніша, чиста метрика.