Параметризовані тести - Коли і для чого ви їх використовуєте?

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

Я бачив поки що тести, які, принаймні, використовують JUnit в межах Eclipse:

• Недолік деталей - коли тест не вдається, дуже важко побачити параметри, які спричинили його збій
• Часто складно створити
• Як правило, створюється після написання коду - строго не є недоліком як таким, але чи люди ставлять перед собою параметризовані тести на увазі, коли вони починають фрагмент коду?

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

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

Ідея полягає в тому, що, хоч ви і не випробовуєте вичерпно, більшість дефектів спричиняють виникнення «області несправностей», а не ізольованої точки. Підхід DOE відстоює Phadke, використовуючи ортогональні масиви, відбирає простір параметрів досить тонко, щоб потрапити на всі можливі області несправностей.

Ізольовані несправності, ймовірно, не будуть ідентифіковані, але їх, як правило, менше, ніж областей розломів.

Підхід DOE дає вам систематичний спосіб вибору значень параметрів для зміни.

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

Існують щонайменше два смаки параметризованих тестів, принаймні, у JUnit 4.8. Це: Параметризовані тести ( @RunWith(Parameterized.class)), для яких потрібне джерело даних, яке генерує / зчитує заздалегідь задані конфігурації параметрів, і Теорії ( @RunWith(Theories.class)), які, даючи один або більше наборів можливих входів для кожного типу аргументів, можуть здійснювати специфікацію заданих методів. Це виглядає більш-менш так:

• укажіть деякі можливі значення ( @DataPoints) для аргументів рядків (наприклад null, порожня рядок, не порожня рядок, дійсно довга рядок)
• задайте деякі можливі значення ( @DataPoints) для аргументів класу Animal (наприклад null, Dogекземпляр, Catекземпляр, Birdекземпляр)
• підготувати @Theoryякий приймає Stringпараметр і Animalпараметр. він буде виконуватися при будь-якій можливій комбінації можливих значень параметрів (у наведеному прикладі, що має бути 4х4 = 16 комбінацій, включаючи ( null, null))
• якщо тестований метод не може прийняти якусь комбінацію, використовуйте Assume.assumeThatстатичний імпорт, щоб відфільтрувати недійсні комбінації (наприклад, коли ви хочете перевірити поведінку методу на непорожні рядки, одним із перших рядків буде "припустити, що це не нуль"

Як було написано раніше - не має сенсу перевіряти кожну можливу комбінацію кожного методу (вона вибухає тестові набори, уявіть тестування методу з 5 параметрами, кожен з яких має лише 5 можливих значень: 5 ** 5 -> понад 3000 тестових пробігів !), але для критично важливих для місії методів (наприклад, методів API) я б заохочував це, просто щоб бути в безпеці ...

Загальний приклад:

• Методи з аргументами рядків. Використовуйте параметризовані тести для тестування різних входів та очікуваних результатів. Набагато практичніше мати список пар (вхідні, очікувані), ніж писати ТС для кожної пари.

• Застосовуйте один і той же сценарій до різних аргументів. У нас є сценарій , який працює з Animalоб'єктом і мати багато підкласів , такі як Dog, Cat, Bird. Створіть список доступних тварин і протестуйте сценарій на них.

Бетон для веб-сервісу:

• З наведеного вище прикладу аргументів. Перевірте, що відбувається з різними аргументами одного типу, але різними значеннями.

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

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

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

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