Прибуток:
- Здатність запобігти прийняттю штучним інтелектом помилкової поведінки як «правильної» шляхом обчислення очікуваного значення в модульних тестах незалежно від правила прийняття
- Можливість друкувати швидкі, незалежні та повторювані тести, застосовуючи принципи AAA та FIRST та висміюючи зовнішні залежності
- Можливість тестувати тести з мутацією (злам коду) і розпізнавати складний для тестування код як запах дизайну
Найбільшим і найшвидшим рівнем піраміди тестування є модульне тестування — тестування, яке перевіряє функцію або невеликий фрагмент коду окремо від усього іншого. Тисячі модульних тестів виконуються за лічені секунди та виявляють помилку, поки код все ще знаходиться на екрані розробника. Штучний інтелект (ШІ), мабуть, найбільш вправний у створенні одиничних тестів: ви надаєте йому функцію, ШІ створює десятки тестів. Але саме ця зручність породжує найбільшу пастку: ШІ легко створює тести, які «світяться зеленим, але нічого не перевіряють» або приймають поточну (можливо, помилкову) поведінку коду як «правильну». У цьому розділі ви дізнаєтесь, як писати справді захисні модульні тести за допомогою штучного інтелекту та зв’язок між тестованим кодом і штучним інтелектом.
Якості хорошого модульного тесту: ПЕРШЕ
Хороші модульні тести дотримуються принципів FIRST: швидкий, незалежний (тести не повинні залежати один від одного), повторюваність (повторюваність — той самий результат у будь-якому середовищі), самоперевірка (чітко пройдено/не пройдено), своєчасно (вчасно). Нагадайте собі про ці принципи, коли ШІ створює тести; спеціально попросіть, щоб тест не залежав від зовнішнього світу (фактичної бази даних, мережі, годинника), щоб був «незалежним» і «повторюваним».
Шаблон AAA та виразне твердження
Надійний модульний тест відповідає структурі AAA: Arrange (підготовка — налаштування входів і залежностей), Act (execute — виклик тестованої функції), Assert (validate — порівняння результату з очікуваним значенням). Критичним є ствердження. Найпоширеніша помилка штучного інтелекту полягає в тому, що він отримує твердження з результатів перевіреного коду — логіка «все, що повертає код, є правдою». Це робить тест безглуздим. Правильно визначити очікуване значення самостійно (з критеріїв прийнятності розрахувати вручну).
Увага: якщо ви скажете ШІ «написати тест для цієї функції», ШІ може запустити функцію та записати її вихід як «очікуваний». Цей тест проходить, навіть якщо функція false. Натомість скажіть «ви обчислюєте очікувані результати відповідно до цих правил, не посилайтеся на поточний вихід функції».
Макети, заглушки та залежності
Модульне тестування вимагає ізоляції. Якщо ваша функція залежить від бази даних або API, під час тестування вони замінюються макетними об’єктами (mock/stub — контрольований, фіктивний замінник справжньої залежності). Це робить тест швидким, незалежним і відтворюваним. AI може створювати імітацію встановлення; Але остерігайтеся надмірного глузування: якщо ви кепкуєте над усім, тест перевірить лише те, що повертає макет, а не справжню логіку. Баланс: імітуйте зовнішній світ, виконуйте реальну логіку під час тестування.
Тестування та ШІ
Є цікавий відгук: код, який важко протестувати, часто погано розроблений. Якщо ШІ має проблеми з написанням тестів для функції (занадто багато залежностей, прихований глобальний стан, побічні ефекти), це запах дизайну. Запитання штучного інтелекту «як би ви переробили цей код, щоб зробити його придатним для тестування» призводить як до кращого тестування, так і до кращого коду.
Параметризовані тести та різноманітність даних
Написання кожного разу окремого тесту для перевірки того самого правила з різними вхідними даними є водночас стомлюючим і важким у підтримці. Параметризоване тестування — структура, яка багаторазово запускає ту саму логіку тестування зі списком вхідних даних і очікуваних результатів — усуває це повторення: одне тестове тіло подається десятками пар вхідних даних. Штучний інтелект дуже ефективний у створенні цих таблиць очікуваних вхідних даних, коли ви надаєте йому свої правила прийняття; Зокрема, систематично зведені в таблиці граничні значення та класи еквівалентності.
Але тут також є пастка: штучний інтелект прагне отримати очікувані результати в згенерованій таблиці з тестованого коду. Ця помилка ще більш небезпечна в параметризованому тестуванні, оскільки одна неправильна логіка робить недійсними десятки рядків. Тому завжди обчислюйте стовпець очікуваного результату незалежно відповідно до правила прийняття та перевіряйте вручну принаймні кілька рядків. Також попросіть стовпець опису «що представляє кожен рядок»; тому, коли рядок розривається, ви миттєво бачите, який стан порушено.
Порада: навмисно додайте «рядок перехоплення» до параметризованої тестової таблиці — тобто свідомо неправильно введіть результат. Якщо ця лінія не стає червоною під час виконання тесту, ваш тест фактично не перевіряє цю ситуацію. Це швидка пробна перевірка.
Слабка підказка / Сильна підказка
Слабкий: «Напишіть модульний тест для цієї функції».
Сильно: Напишіть модульні тести [мова/фреймворк] для функції "taxCalculate(сума, ставка). Правило прийняття: результат = сума * ставка, округлена до 2 знаків після коми; від’ємна сума або ставка видає помилку; повертає 0, якщо ставка дорівнює 0. Використовуйте структуру AAA. Вручну обчислюйте очікувані значення відповідно до ЦИХ правил; не посилайтеся на поточний результат функції. Охоплюйте обмежені та негативні випадки (0, від’ємний, дуже Нехай назва кожного тесту описує зовнішню залежність "Ні".
Потужна підказка; Він дає правило прийняття, незалежне очікуване очікуване значення, структуру та граничні випадки. Таким чином, тест стає охоронцем правила, а не дзеркалом коду.
Таблиця якості одиничних тестів
симптом
Поганий тест (фальшива довіра)
хороший тест
стверджувати
Немає або "не нуль"
Очікувана конкретна вартість
Очікуване джерело значення
Вихід функції
Правило приймання / розрахунок вручну
залежність
Фактична БД/мережа/год
Ізольований макетом/заглушкою
крайовий корпус
Тільки щасливої дороги
межа, негатив, помилка
Коли ви зламаєте код
залишається зеленим
стає червоним
Ім'я
test1, testMethod
описує правило, яке воно підтверджує
Чотири шаблони, які можна копіювати
1) Модульне тестування на основі правил:
Ваша роль: старший інженер з тестування програмного забезпечення. Напишіть модульний тест для такої функції з [мова/фреймворк]: [підпис]. Правила прийняття: [правила]. - Використовуйте структуру AAA. - Вручну обчисліть очікувані значення відповідно до ЦИХ правил; НЕ посилайтеся на поточний вихід функції. - Покрийте ліміт, негатив, помилку та щасливий шлях окремими тестами. - Нехай кожна назва тесту описує правило, яке воно перевіряє. - Імітація зовнішніх залежностей; Примусьте справжню логіку працювати.
2) Контроль стійкості до мутацій:
Check out these unit tests. Перелічіть 5 незначних змін, які я міг би зробити в тестованому коді (a - замість +, a >= замість >, зміщення межі) і скажіть мені для кожного, ЯКИЙ із цих тестів стане червоним? Якщо жоден не повертається, тест недостатній. Код + тести: [вставити]
3) Огляд придатності до тестування:
Чому важко написати модульний тест для цієї функції? Прихована залежність, глобальний статус, побічні ефекти, чи багато обов’язків? Запропонуйте мінімальний рефакторинг, щоб зробити його тестованим; не змінювати поведінку. Код: [вставити]
4) Неповне завершення сценарію:
Наведено наступні функції та доступні тести. Перелічіть, яка поведінка/граничний випадок НІКОЛИ не тестувався (недолік області видимості) і додайте тест для кожного. Функція+тести: [вставити]
три міні-чохла
Випадок 1 — Тестове віддзеркалення коду. Розробник попросив ШІ написати тест для функції округлення; 10 тестів були зеленими. Насправді функція округлювала в неправильному напрямку, але AI взяв очікувані значення з виводу функції, тому тести вважали помилку «істинною». Коли очікувані значення були розраховані вручну за допомогою шаблону «на основі правил», 4 тести стали червоними, і виявилася справжня помилка.
Випадок 2 — значення контролю мутацій. Одна команда покладалася на 45 модульних тестів. Спробував 20 незначних змін коду з «перевіркою надійності мутації»; тести виявили лише 11 із них. Решта 9 збоїв пройшли тихо. Команда посилила слабкі тести; Ці розширені тести в наступному випуску виявили фактичну помилку розрахунку.
Випадок 3 — Нетестування — це запах дизайну. ШІ не міг писати тести для функції впорядкування, йому постійно потрібна була справжня база даних. Шаблон «перевірка тестоздатності» показав, що функція вбудованого доступу до бази даних. Коли впровадження залежностей було видалено, можна було писати тести, а код став чистішим.
Поширені помилки
- Отримання очікуваного значення з коду. AI приймає вихід функції як «правильний»; тест, який підтверджує помилковий код.
- Тест без твердження або з тривіальним твердженням. «Він не видав помилку, він пройшов» логіку; Це нічого не підтверджує.
- Екстремальний макет. Висміювання всього і тестування лише того, що повертає макет; справжня логіка не перевіряється.
- Просто щаслива дорога. Обхід граничних, негативних і помилкових станів.
- Не тестування шляхом зламу коду. Довіряючи зеленому, не перевіряючи мутації.
- Ігнорування неперевіреності. Не розпізнавати та виправляти поганий дизайн замість наполегливого тестування.
Підсумовуючи
Модичні тести є найшвидшим і найбільшим шаром піраміди тестування; Він ловить помилку в найдешевший момент. Штучний інтелект дуже здатний створювати модульні тести, але його найбільша підводне каміння полягає в написанні тестів, які припускають неправильну поведінку як «правильну», витягуючи очікуване значення з самого коду. Рішення: надайте правила прийняття, обчисліть очікувані значення вручну, запровадьте принципи AAA та FIRST, висміюйте зовнішній світ і запустіть справжню логіку, а також перевіряйте кожен тест шляхом мутації (порушення коду). Код, який важко перевірити, є ознакою дизайну, який потребує виправлення.
Аплікаційне завдання
Виберіть функцію, яка містить бізнес-правило з вашого власного проекту. Напишіть правила прийому та створіть тести ШІ за допомогою шаблону «модульне тестування на основі правил»; Розрахуйте очікувані значення вручну. Потім застосуйте «перевірку стійкості мутації»: зробіть принаймні 5 невеликих розривів у коді та виміряйте, скільки тестів стає червоним. Додайте новий тест на невловлені пошкодження. Повідомте, скільки збоїв було виявлено (наприклад, показник мутації).
контрольний список
- [ ] Я дав правила прийняття та розрахував очікувані значення вручну.
- [ ] Я переконався, що тести не виводять очікуване значення з коду.
- [ ] Я запровадив незалежне тестування відповідно до рекомендацій AAA та FIRST.
- [ ] Я висміяв зовнішні залежності та запустив фактичну логіку.
- [ ] Я розглядав обмеження, негативні випадки та помилки.
- [ ] Зламавши код (мутація), я довів, що тести справді захищають.