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

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

Ця проза Альберто Савойї відповідає саме на це питання (приємно розважаючи це!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Тестівус на тестовому покритті

Рано одного ранку програміст запитав у великого майстра:

«Я готовий написати кілька тестів на одиницю. До якого покриття коду я повинен прагнути? "

Великий майстер відповів:

"Не хвилюйтеся про покриття, просто напишіть кілька хороших тестів".

Програміст посміхнувся, вклонився і пішов.

...

Пізніше того ж дня другий програміст задав те саме питання.

Великий майстер вказав на горщик з окропом і сказав:

"Скільки зерен рису я повинен покласти в той горщик?"

Програміст, дивлячись спантеличено, відповів:

"Як я можу вам сказати? Це залежить від того, скільки людей потрібно годувати, наскільки вони голодні, яку іншу їжу ви подаєте, скільки рису у вас є і так далі ».

- Саме так, - сказав великий майстер.

Другий програміст посміхнувся, вклонився і пішов.

...

Наприкінці дня прийшов третій програміст і задав те саме питання щодо висвітлення коду.

"Вісімдесят відсотків і не менше!" - відповів майстер суворим голосом, ударивши кулаком по столу.

Третій програміст посміхнувся, вклонився і пішов.

...

Після цієї останньої відповіді молодий учень підійшов до великого майстра:

«Чудовий майстер, сьогодні я почув, що ви відповіли на те саме питання щодо висвітлення коду з трьома різними відповідями. Чому? "

Великий майстер підвівся зі свого крісла:

"Приходь, принеси зі мною свіжий чай і поговоримо про це".

Коли вони наповнили чашки курінням гарячого зеленого чаю, великий майстер почав відповідати:

«Перший програміст новий і тільки розпочинає тестування. Зараз у нього багато коду і відсутні тести. У нього довгий шлях; зосередження уваги на висвітленні коду в цей час було б гнітючим і зовсім марним. Йому краще просто звикнути писати та виконувати деякі тести. Пізніше він може турбуватися про покриття ».

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

"Я бачу, - сказав молодий учень, - але якщо немає єдиної простої відповіді, то чому ви відповіли третьому програмісту" Вісімдесят відсотків і не менше "?"

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

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

Молодий учень і запечений великий майстер закінчили пити чай у споглядальній тиші.

Покриття коду - оманливий показник, якщо ваша мета - 100% охоплення (замість 100% тестування всіх функцій).

• Ви можете отримати 100%, натиснувши всі лінії один раз. Однак ви все ще можете пропустити тестування певної послідовності (логічного шляху), в яку потрапляють ці рядки.
• Ви не змогли отримати 100%, але все-таки випробували всі кодові шляхи 80% / freq. Проведення тестів, які перевіряють кожен "викид ExceptionTypeX" або подібного захисного захисного програмування, який ви ввели, - це "приємно мати", а не повинен "

Тож довіряйте собі чи своїм розробникам ретельні та висвітлювати кожен шлях за допомогою свого коду. Будьте прагматичними і не переслідуйте магічне 100% охоплення. Якщо ви TDD-код, ви отримаєте 90% + покриття як бонус. Використовуйте кодове покриття, щоб виділити шматки коду, який ви пропустили (не повинно статися, якщо ви TDD, хоча .. оскільки ви пишете код лише для тестового проходу. Жоден код не може існувати без його тесту партнера.)

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

Мені байдуже, чи маю я код, який не охоплюється тестами, але мені було б байдуже, чи переробляю я код і в кінцевому підсумку маю іншу поведінку. Тому 100% функціональне покриття - моя єдина мета.

Прийнята відповідь дає хороший момент - не існує жодного номера, яке матиме сенс як стандарт для кожного проекту. Є проекти, яким просто не потрібен такий стандарт. Якщо прийнята відповідь не відповідає, на мою думку, полягає в описі того, як можна прийняти це рішення для даного проекту.

Я зроблю знімок при цьому. Я не фахівець з тест-інженерії, і буду рада бачити більш усвідомлену відповідь.

Коли встановити вимоги щодо покриття коду

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

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

Деякі конкретні випадки, коли наявність емпіричного стандарту може додати значення:

• Для задоволення зацікавлених сторін. Для багатьох проектів є різні суб'єкти, які зацікавлені в якості програмного забезпечення, які можуть не брати участь у щоденній розробці програмного забезпечення (менеджери, технічні підказки тощо), кажучи: "Ми збираємось написати всі тести, які нам справді потрібні ", не є переконливими: їм або потрібно повністю довіряти, або перевіряти постійним ретельним наглядом (припускаючи, що вони навіть мають технічне розуміння для цього.) Забезпечення вимірюваних стандартів та пояснення, наскільки вони розумно наближають фактичні цілі.
• Нормалізувати поведінку команди. Зацікавлені сторони, якщо ви працюєте в команді, де кілька людей пишуть код і тести, є місце для неоднозначності щодо того, що кваліфікується як "добре перевірене". Чи всі ваші колеги мають однакове уявлення про те, який рівень тестування достатньо хороший? Напевно, ні. Як ви це погоджуєте? Знайдіть показник, з яким можна погодитись, і прийміть його як розумне наближення. Це особливо (але не виключно) корисно для великих команд, де, наприклад, потенційні клієнти не мають безпосереднього нагляду за молодшими розробниками. Мережі довіри також мають значення, але без об'єктивних вимірювань групова поведінка легко стає непослідовною, навіть якщо всі діють добросовісно.
• Щоб бути чесним. Навіть якщо ви єдиний розробник і єдиний зацікавлений у вашому проекті, ви можете мати на увазі певні якості для програмного забезпечення. Замість того, щоб робити постійні суб'єктивні оцінки того, наскільки добре перевірене програмне забезпечення (яке вимагає роботи), ви можете використовувати покриття коду як розумне наближення, і дозвольте машинам вимірювати його для вас.

Які показники використовувати

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

Я буду використовувати дві загальні показники як приклади, коли ви можете використовувати їх для встановлення стандартів:

• Покриття заяви : Який відсоток тверджень було виконано під час тестування? Корисно для розуміння фізичного висвітлення вашого коду: Яку кількість написаного коду я фактично перевірив?
  • Цей вид покриття підтримує слабший аргумент коректності, але його також легше досягти. Якщо ви використовуєте тільки покриття коду , щоб переконатися , що все перевіритися (а не в якості показника якості тесту за що) , то заяву покриття, ймовірно , досить.
• Охоплення гілки : Якщо існує логіка розгалуження (наприклад, an if), чи були оцінені обидві гілки? Це дає краще розуміння логічного висвітлення вашого коду: Скільки можливих шляхів проходження мого коду я протестував?
  • Цей вид покриття є набагато кращим показником того, що програма була протестована на всебічному наборі даних. Якщо ви використовуєте кодове покриття як найкраще емпіричне наближення для впевненості у правильності, вам слід встановити стандарти на основі покриття галузей чи подібних.

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

Який відсоток вимагати

Нарешті, повернемось до початкового питання: Якщо ви встановлюєте стандарти покриття коду, яким повинен бути цей номер?

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

Деякі цифри, які можна вибрати:

• 100% . Ви можете вибрати це, тому що хочете бути впевненим, що все перевірено. Це не дає тобі уявлення про якість тесту, але говорить про те, що деякий тест на якусь якість торкнувся кожної заяви (або гілки тощо). Знову ж таки це повертається до певної ступеня впевненості: Якщо покриття не нижче 100% , ви знаєте, що підмножина вашого коду не перевірена.
  • Деякі можуть стверджувати, що це нерозумно, і вам слід перевірити лише ті частини коду, які є дійсно важливими. Я заперечую, що ви також повинні підтримувати лише ті частини коду, які є дійсно важливими. Покриття коду можна покращити, видаливши також неперевірений код.
• 99% (або 95%, інші цифри у високих дев'яностих). Підходять у випадках, коли ви хочете донести рівень довіри, подібний до 100%, але залиште собі певний запас, щоб не турбуватися про випадковий важко перевірений куточок код.
• 80% . Я бачив це число в користуванні кілька разів, і не зовсім знаю, звідки воно походить. Я думаю, що це може бути дивне присвоєння правила 80-20; загалом наміром тут є показати, що найбільше вашого коду перевірена. (Так, 51% також було б "більшістю", але 80% більше відображає те, що більшість людей має на увазі під собою.) Це підходить для середніх випадків, коли "добре перевірений" не є першочерговим завданням (ви не " не хочете витрачати зусилля на тести з низькою вартістю), але це достатньо пріоритету, який ви все-таки хочете мати на своєму ринку.

На практиці я не бачив цифр нижче 80%, і важко уявити собі випадок, коли їх можна було б встановити. Роль цих стандартів полягає у підвищенні впевненості у правильності, і цифри нижче 80% не особливо надихають довіри. (Так, це суб'єктивно, але знову ж таки, ідея полягає в тому, щоб зробити суб'єктивний вибір один раз, коли ви встановите стандарт, а потім використовувати об'єктивне вимірювання вперед.)

Інші примітки

Сказане передбачає, що правильність - мета. Кодове покриття - це лише інформація; це може бути відносно інших цілей. Наприклад, якщо ви стурбовані технічним обслуговуванням, ви, мабуть, піклуєтеся про нещільне з'єднання, що може бути продемонстровано тестабельністю, яка, в свою чергу, може бути виміряна (певним чином) за допомогою покриття коду. Таким чином, ваш стандарт покриття коду дає емпіричну основу для наближення до якості "ремонтопридатності".

Моє улюблене покриття коду - 100% із зірочкою. Зірочка з'являється тому, що я вважаю за краще використовувати інструменти, які дозволяють мені позначати певні рядки рядками, які "не враховуються". Якщо я покрив 100% рядків, які "рахуються", я закінчую.

Основний процес:

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

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

У мене буде ще один анектод на тестовому покритті, яким я хотів би поділитися.

У нас є величезний проект, в якому під час щебетання я зазначив, що з 700 одиничних тестів ми маємо лише 20% покриття коду .

Скотт Гензельман відповів словами мудрості :

Це ПРАВО 20%? Це 20%, який представляє код, який найбільше вразили ваші користувачі? Ви можете додати ще 50 тестів і лише 2%.

Знову ж таки, це стосується мого відповіді Тестівуса на кодове покриття . Скільки рису потрібно покласти в горщик? Це залежить.

Для добре розробленої системи, де одиничні тести керували розвитком з самого початку, я б сказав, що 85% - це досить низька кількість. Невеликі класи, призначені для перевірки, не повинні бути важкими для покриття краще за це.

Це питання легко відкинути таким чином:

• Покриті рядки не відповідають рівню перевіреної логіки, і не слід занадто багато читати у відсотках.

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

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

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

• Низький показник води (LWM) - найменша кількість непокритих ліній, що коли-небудь бачились у тестуваній системі
• Висока марка води (HWM), найвищий відсоток покриття коду, який коли-небудь бачили для тестуваної системи

Новий код може бути доданий лише у тому випадку, якщо ми не виходимо вище LWM і не підходимо нижче HWM. Іншими словами, покриття кодом не дозволяється зменшуватися , а новий код повинен бути охоплений. Зверніть увагу, як я кажу, що потрібно, а не потрібно (пояснено нижче).

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

• Просувається тестовий код. Додаючи новий код, ви дійсно повинні докласти зусиль, щоб зробити код перевіряючим, тому що вам доведеться спробувати покрити все це своїми тестовими кейсами. Тестовий код, як правило, хороша річ.

• Покриття тесту застарілим кодом з часом збільшується. Додаючи новий код і не в змозі прикрити його тестовим випадком, можна спробувати охопити якийсь застарілий код замість цього, щоб обійти правило LWM. Це іноді необхідне обман, щонайменше, дає позитивний побічний ефект, що висвітлення застарілого коду з часом збільшиться, що зробить, здавалося б, суворе виконання цих правил досить прагматичним на практиці.

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

Я також хотів би зазначити ще дві загальні переваги метрики покриття коду.

• Аналіз покриття коду є частиною динамічного аналізу коду (на відміну від статичного, тобто Lint). Проблеми, виявлені під час динамічного аналізу коду (за допомогою таких інструментів, як сім'я очищення, http://www-03.ibm.com/software/products/en/rational-purify-family ), - такі речі, як неініціалізовані читання пам'яті (UMR), витоки пам'яті тощо. Ці проблеми можна знайти, лише якщо код охоплений виконаним тестовим випадком . Код, який найскладніше охопити в тестовому випадку, як правило, це ненормальні випадки в системі, але якщо ви хочете, щоб система вийшла вишукано (тобто слід помилки замість аварії), ви можете докласти певних зусиль для висвітлення аномальних випадків в динамічному аналізі коду. Завдяки трохи невдачі, UMR може призвести до сегмента або ще гірше.

• Люди пишаються тим, що на 100% зберігають новий код, і люди обговорюють проблеми тестування з подібною пристрастю, як і інші проблеми з реалізацією. Як цю функцію можна записати більш перевіреним? Як би ви намагалися висвітлити цю ненормальну справу тощо.

І негатив, для повноти.

• У великому проекті з багатьма залученими розробниками кожен точно не стане геніальним тестом. Деякі люди схильні використовувати метрику покриття коду як доказ того, що код перевірений, і це дуже далеко від істини , про що йдеться у багатьох інших відповідях на це питання. Це ОДИН показник, який може принести корисні переваги при правильному використанні, але при неправильному використанні це може призвести до поганого тестування. На відміну від дуже цінних побічних ефектів, згаданих вище, накрита лінія показує лише, що система, що перевіряється, може досягти цієї лінії для деяких вхідних даних і що вона може виконуватись без вивішування або збоїв.

Якби це був ідеальний світ, 100% коду покривали б одиничні тести. Однак, оскільки це НЕ ідеальний світ, це питання того, на що у вас є час. Як результат, я рекомендую менше зосереджуватися на конкретному відсотку та більше зосереджуватися на критичних областях. Якщо ваш код добре написаний (або принаймні розумний факсимільний код), повинно бути кілька ключових моментів, де API-інтерфейси піддаються іншому коду.

Сфокусуйте свої тестові зусилля на цих API. Переконайтеся, що в API 1) добре задокументовані та 2) написані тестові випадки, які відповідають документації. Якщо очікувані результати не збігаються з документами, ви маєте помилку в коді, документації або тестових випадках. Все це добре перевірити.

Удачі!

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

У світі .Net люди часто наводять 80% як міркування. Але вони говорять про це на рівні рішення. Я вважаю за краще оцінювати на рівні проекту: 30% може бути добре для проекту інтерфейсу, якщо у вас є Selenium, тощо або ручні тести, 20% для проекту рівня даних може бути добре, але 95% + може бути цілком досяжним для бізнесу Правила шару, якщо не повністю необхідна. Таким чином, загальне покриття може бути, скажімо, 60%, але критична логіка бізнесу може бути набагато вищою.

Я також чув це: прагніть до 100%, і ви наберете 80%; але прагніть до 80%, і ви наберете 40%.

Підсумок: застосуйте правило 80:20, і нехай підрахунок помилок вашої програми керує вами.

Покриття коду - лише черговий показник. Саме по собі це може бути дуже оманливим (див. Www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated ). Ваша мета не повинна полягати в тому, щоб досягти 100% покриття коду, а забезпечити тестування всіх відповідних сценаріїв вашої заявки.

85% було б хорошим початковим місцем для критеріїв реєстрації.

Я, мабуть, вибрав різноманітні більш високі смуги для критеріїв доставки - залежно від критичності перевірених підсистем / компонентів.

Я використовую кобертуру, і який би відсоток не був би, я б рекомендував постійно оновлювати значення в задачі перевірки кобертуару. Як мінімум, продовжуйте піднімати загальний та загальний розміри до нижчого рівня поточного покриття, але ніколи не знижуйте цих значень. Також прив’яжіть до цього завдання властивість відмови побудови мурашок. Якщо збірка не вдається через відсутність покриття, ви знаєте, чийсь доданий код, але не перевірив його. Приклад:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

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

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

Це стосується коду, який не охоплюється, охоплюється 50% або 97%.

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

Якщо убік, відповідь залежить від вашої методології, мови та інструментів тестування та висвітлення. Коли ви робите TDD в Ruby або Python, не важко підтримувати 100% покриття, і це варто зробити так. Набагато простіше керувати 100% покриттям, ніж 90-відсоткове покриття. Тобто, набагато простіше заповнити прогалини в покритті, як вони з’являються (а якщо робити TDD добре, прогалини в покритті рідкісні і зазвичай варті вашого часу), ніж керувати списком прогалин покриття, до яких ви не потрапили, і пропустити покриття регресії через постійний фон непокритого коду.

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

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

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

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

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

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

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

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

Коротка відповідь: 60-80%

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

Перевірте Crap4j . Це дещо складніший підхід, ніж пряме висвітлення коду. Він поєднує вимірювання покриття коду з вимірюваннями складності, а потім показує, який складний код на даний момент не перевіряється.

Моя відповідь на цю загадку - мати 100% покриття рядка коду, який ви можете протестувати, і 0% покриття рядка коду, який ви не можете перевірити.

Моя теперішня практика в Python - це поділ моїх .py модулів на дві папки: app1 / і app2 /, і під час запуску тестових одиниць обчислюють охоплення цих двох папок і візуально перевіряють (я повинен автоматизувати це колись), що app1 має 100% покриття і app2 має 0% покриття.

Коли / якщо я виявлю, що ці цифри відрізняються від стандартних, я досліджую і змінюю дизайн коду, щоб покриття відповідало стандарту.

Це означає, що я можу рекомендувати досягти 100% покриття рядка бібліотечного коду.

Я також періодично переглядаю app2 /, щоб побачити, чи можу я перевірити будь-який код там, і якщо я можу перенести його в app1 /

Зараз я не надто переживаю сукупне покриття, тому що це може різко змінюватися залежно від розміру проекту, але, як правило, я бачив від 70% до понад 90%.

За допомогою python я маю змогу розробити тест на дим, який міг би автоматично запустити мою програму під час вимірювання покриття та, сподіваємось, набрати 100% сукупності при поєднанні тесту на дим із показниками unittest.

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

На мою думку, відповідь «Це залежить від того, скільки у вас часу». Я намагаюся досягти 100%, але я не шуміть, якщо не отримую цього з часом.

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

Я зазвичай дотримуюся таких критеріїв або правил:

1. Що Unit Test повинен бути формою документації щодо того, яка очікувана поведінка моїх кодів, тобто. очікуваний вихід із певним вкладом та винятки, які клієнти можуть захотіти зловити (Що повинні знати користувачі мого коду?)

2. Те, що блок-тест повинен допомогти мені виявити, що робити, якщо умови, про які я, можливо, ще не думав. (Як зробити мій код стабільним і надійним?)

Якщо ці два правила не дають 100% покриття, так і нехай буде. Але одного разу, я маю час, я аналізую непокриті блоки та рядки та визначаю, чи все ще є тестові випадки без одиничних тестів або чи потрібно переробити код, щоб усунути непотрібні коди.

Це дуже залежить від вашої заявки. Наприклад, деякі програми складаються здебільшого з GUI-коду, який не можна перевірити на одиницю.

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

Залежно від критичності коду, десь від 75% -85% - це хороше правило. Код доставки, безумовно, слід перевірити ретельніше, ніж у комунальних послугах тощо.

Це повинно залежати від того, на якій фазі життєвого циклу розробки вашої програми ви перебуваєте.

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

Залежно від вашого домену, це нерозумно стріляти на 95%, але я мушу сказати, що в середньому ви будете шукати середній випадок від 85% до 90%.

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

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

Ми орієнтувались на> 80% до декількох днів тому, але після того, як ми використовували багато згенерованого коду, ми не піклуємося про% вік, а швидше змушуємо рецензента зателефонувати за необхідним покриттям.

З моменту публікації Testivus, я думаю, що контекст відповіді повинен бути другим програмістом. Сказавши це з практичної точки зору, нам потрібні параметри / цілі, до яких слід прагнути. Я вважаю, що це можна «перевірити» в Agile процесі, проаналізувавши код у нас, архітектуру, функціональність (розповіді користувачів), а потім придумати число. Виходячи з мого досвіду в галузі телекомунікацій, я б сказав, що 60% - це хороше значення для перевірки.