Як люди підтримують свій тестовий набір?

Зокрема, мені цікаво наступні аспекти:

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

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

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

Довга відповідь:

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

• Використовуючи засоби покриття коду, такі як Cobertura , ви зможете виявити, що тестові випадки для даного класу або складні методи вже не є достатніми. Вам не потрібно всюди охоплювати 100% покриття коду, і в більшості випадків це буде важко досягти і не обов'язково корисно; але тести на найважливіші аспекти програми повинні підтримуватися з метою принаймні 80% покриття коду.
• Використовуючи засоби безперервного збирання та інтеграції , такі як Дженкінс, які мені дуже подобаються, у поєднанні з плагіном Sonar ви можете встановити тригери, які надсилають електронні листи та інші типи сповіщень особам, відповідальним за останні зміни. Різні графіки та статистичні дані (Sonar також використовує Cobertura серед багатьох інших інструментів) допомагають рецензентам коду та розробникам тестових випадків зосередитись на тому, що є критичним.

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

Те, що я написав на перше запитання, є частиною відповіді на ваше друге запитання. Я також додам тут наступні моменти:

• Напишіть тестові приклади інтеграції (або "ділові" випадки, якщо вам зручніше) на додаток до тестових випадків. Вони, швидше за все, спочатку змінюються / перерваються, оскільки вони часто залежать від декількох класів / методів. А оскільки вони часто ламаються, менше шансів забути. Єдиний підхід / методологія, яка, з мого особистого досвіду, допомагає писати хороші тести, - це Test-Driven Development . Особливо, якщо особа, яка пише тестовий випадок, НЕ та сама особа, яка пише код для цього. Написання хороших тестових випадків за допомогою TDD також вимагає часу, але результати, принаймні для мене, були надзвичайно задовільними.
• Щоразу, коли виходить помилка, напишіть виправлення та тестовий випадок, що йде разом із цим. Тестовий випадок повинен охоплювати лише цю помилку. Оскільки ви повністю покрили код, який відповідає за помилку, він більше не повинен виходити.

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

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

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

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