Створення тестування автоматизованого блоку

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

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

Мене особливо цікавлять методи створення одиничних тестових скелетів у PHP, які не містять усіх інструментів, які надають інші мови, наприклад, повного натяку на тип , наприклад.

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

Досить прямо вперед написати тестовий генератор, який для таких мов, як C або Java, зчитує підписи класів і автоматично генерує тести для стандартних кутових випадків (передаючи 0, 2 випадкових значення, MAX_INT, MIN_INT, на цілий аргумент, нулі для нульових значень тощо). Потім можна запустити згенеровані тести, записати результати для кожного тесту та вручну фільтрувати їх, щоб видалити невідповідні, затвердити прийнятні результати для тестів, які проходять (щоб вони потім могли автоматично проходити далі) та позначити як недійсні, які не вдалися .

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

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

• Компонент для автоматичного розбору вихідних кодів / підписів функцій / ручних анотацій, створення стандартних тестових випадків або контур / підписів для тестових випадків, які чекають завершення вашого вводу.
• Постійно зростаюча / мінлива мова тегів / анотацій / коментарів, яка може переходити на будь-який рівень деталізації (метод / клас / підпис / під час циклів / тощо), що представляє підказки автоматизованому конструктору тестів. В ідеалі ви повинні мати можливість грати з цією мовою, не перекодуючи свій фреймворк або будь-які шматки в ньому
• Автоматизований тест-бігун, з можливістю ідентифікувати нові / старі тести та записувати / тестувати проти "прийнятних" відповідей для кожного тесту. В ідеалі цей бігун створить базу даних пробних пробігів, прийнятих / відхилених результатів та поточних прийнятних результатів для кожного тесту.
• Автоматизований "обробник об'єктів", який, даючи ім'я класу та карту імен-> значень, може генерувати об'єкт, що імітує клас, повертаючи настроювані дані для викликів функцій, аксесуарів, відкритих слотів даних тощо ...

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

У мене ще не було можливості використовувати його в застосуванні значного розміру чи складності, але є інструменти, включаючи CodePro AnalytiX від Google , які автоматизують генерацію одиничних тестів для додатків Java . Я також знайшов комерційний продукт, тест C ++ Parasoft , який, можливо, дозволяє створити тести на C ++

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

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

Тільки для надання більшої реклами, Falcon випробував CodePro над проектом і написав трохи розмиття щодо свого досвіду .

Я написав генератор для прискорення тестування одиниць для проекту .NET кілька років тому. Була велика база коду без тестових одиниць, і вона мала на меті швидке збільшення базового покриття. Ось кілька записок, які можуть бути корисними:

• Моя ймовірність полягала в тому, що основна основа, над якою розроблявся проект, забезпечувала стандартні операції та імена класів. Якщо ви думаєте написати власну, стандартна структура на зразок цієї допоможе дуже.
• Використання дуже data-driven testingдопомагає, якщо це дозволяє ваша база коду. Тестовий фреймворк створив таблицю бази даних для кожного тесту одиниць для зберігання тестових даних, так що кожен рядок у цій таблиці був окремим тестом і не потрібен додатковий код ( Правило представлення ). З цього моменту фактичні тести можна легко створити автоматично або ввести вручну.
• Отримані одиничні тести були простими, але вони smoke testпринаймні служили s. Для областей підвищеного ризику були написані додаткові тести вручну.

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

(В якості побічної ноти, є Pex , але це для .NET)