Прибуток:
- Можливість проводити модульне тестування, крайові випадки та аналіз прогалин покриття за допомогою ШІ
- Можливість друку очікувань тесту на основі специфікації, а не поточної поведінки коду
- Можливість перевірити, чи справді тест захищає шляхом введення помилок
Написання тестів — одне з найбільш цінних завдань, яке більшість розробників відкладає. Хороший набір тестів є доказом того, що код працює належним чином, і рятівним кругом для майбутніх змін. Проблема полягає в тому, що написання тестів є повторюваним і трудомістким — це саме та робота, у якій ШІ сяє. Але є заковика: ШІ часто перевіряє існуючу поведінку коду, а не поведінку, якою вона має бути. Управління цією різницею є суттю цього підрозділу.
У цьому розділі ви дізнаєтеся про модульне тестування (тестування, яке перевіряє функцію окремо, ізольовано), тестування крайових випадків і генерування тестових даних за допомогою ШІ; усунення прогалин у охопленні тестами; і чому сліпо довіряти тестам ШІ небезпечно.
Дві сторони тестування: фіксація поведінки проти перевірки
Тест може служити двом різним цілям. По-перше, це перевірка: вона перевіряє, чи правильний код, чи відповідає він специфікації. По-друге, захист від регресії: він заморожує поведінку коду сьогодні, тож якщо хтось випадково змінить його завтра, тест зламається та повідомить.
ШІ дуже добре справляється з останнім; Він переглядає код і генерує випадки, які перевіряють, «що він робить прямо зараз». Але якщо код неправильний із самого початку, ШІ може закріпити цю неправильну поведінку як «правильну». Тож ви повинні переглянути твердження кожного тесту, який створює ШІ: «Код повертає 42, а тест очікує 42» не означає, що 42 є правильною відповіддю.
Застереження: якщо ШІ проходить перевірку, це не означає, що код «робочий»; це просто означає "він поводиться так, як очікує AI". Переглядаючи специфікацію, ви вирішуєте, чи є очікування правильним чи ні.
Крок за кроком: написання надійних тестів за допомогою ШІ
- Надайте специфікацію, а не лише код. Якщо ви додаєте інформацію «Ця функція повинна робити це», AI може написати правильне очікування; Він перевірить поточну поведінку, якщо ви просто надасте код.
- Попросіть крайні випадки. Порожній, нульовий, нульовий, негативний, завеликий, поганий формат, одночасність — явно стверджуйте, що зійшов із щасливого шляху.
- Укажіть структуру та стиль тестування. "використовувати pytest", "шаблон Arrange-Act-Assert", "нехай кожен тест перевіряє одну річ" тощо.
- Перевірте очікування (твердження). Порівняйте зі специфікацією, що кожне твердження перевіряє правильне значення.
- Закрити прогалини в області застосування. Наведіть існуючі тести та запитайте "які гілки та кейси не перевірені?" змусити вас запитати; потім перевірити проведені додаткові тести.
Три міні-чохли
Випадок 1 — Покриття від 52% до 85%. Тестове покриття одного сервісного модуля склало 52%. Команда передала ШІ наявні тести, змусила його створити список неперевірених гілок і створити для них тести. Завдяки перевірці людиною охоплення зросло до 85%; У процесі ШІ виявив справжню помилку (шлях, який повертав неправильний код помилки) у гілці помилок, яка ніколи раніше не перевірялася.
Випадок 2 — Пастка фіксації помилкових очікувань. Функція округлення грошей насправді була неправильною; Замість округлення 2,675 до 2,67 було округлено 2,67 замість 2,68. ШІ переглянув код і написав assert round_money(2.675) == 2.67 — заморозивши помилку як «true». Коли розробник прочитав специфікацію, він виправив очікування та виявив справжню помилку. Тестування правила, а не коду мало значення.
Випадок 3 — вибух крайового стану. Коли AI запитує лише «граничні випадки» для функції діапазону дат; Він створив 8 випадків, таких як початок=кінець, зворотний інтервал, високосний рік 29 лютого, різні часові пояси та нульовий інтервал. Два з них (зворотний інтервал і високосний рік) насправді спричиняли помилку. Розгляд цих випадків вручну часто пропускається; Штучний інтелект став тут партнером у «мозковому штурмі крайніх випадків».
Чотири шаблони, які можна копіювати
Генерація тестів на основі специфікацій:
Роль: розробник, який пише тести. Фреймворк: {{pytest/JUnit/Jest...}}. Що МАЄ РОБИТИ функція (специфікація): {{rule}}Напишіть тести для такої функції. Напишіть очікування відповідно до специфікації, а НЕ поточного виводу коду. Щасливого шляху + додайте принаймні 4 крайні випадки. Нехай кожен тест перевіряє одну річ, використовуйте описову назву. {{функція}}
Мозковий штурм крайнього випадку:
Перелічіть крайні випадки/випадки збою, які слід спробувати під час тестування цієї функції (null, null, точки зупину, неправильний формат, паралелізм, зовнішня помилка). Для кожного випадку: вхідні дані, очікувана поведінка. НЕ пишіть поки код, просто перерахуйте.{{function}}
Аналіз розриву покриття:
Нижче наведено функції та доступні тести. Які гілки, умови та випадки не перевірені? Перелічіть недоліки та напишіть нові тести лише на недоліки. Не повторюйте існуючі. Функція:{{function}}Тестування:{{existing_tests}}
Тестові дані / створення макетного об'єкта:
Згенеруйте реалістичні тестові дані для тестів {{function/service}}: дійсні зразки, граничні зразки та недійсні зразки окремо. Запропонуйте просту макет поведінки для зовнішньої залежності {{X}}. Використання справжніх конфіденційних даних/ІПІ; Генерувати підроблені дані.
Слабка підказка / Сильна підказка
Слабкий: «Напишіть тест для цієї функції».
Сильний: "з pytest. Функція apply_discount(total, percent) — правило: знижка має бути 0%–30%, поза межами має видавати ValueError, результат має бути округлений до 2 знаків після коми. Запишіть очікування за цим ПРАВИЛОМ (а не за кодом). Щасливий шлях + ці крайні випадки: 0%, 30%, 31% (помилка), негатив, total=0. [код]"
Він дає правило сильного випуску та каже «напишіть очікування відповідно до правила, а не коду»; Це єдине речення закриває пастку ШІ, що виправляє неправильну поведінку.
Тип тесту
внесок ШІ
контроль людини
Щасливого тестування на дорозі
швидкий скелет
Чи правильне очікування?
Крайові корпуси
Широкий мозковий штурм
Виключіть несуттєве
Заповнення прогалин у сфері застосування
Знаходить пропущені гілки
Підтвердити значимість
Тестові дані/макет
Створює реалістичний зразок
Без ідентифікаційної інформації, контроль реалістичності
Тести керують якістю, а не гарантують її
Високе охоплення тестом дає впевненість, але воно також може вводити в оману: 100-відсоткове охоплення означає, що "кожний рядок перевірено", а не "кожний рядок правильний". Легко збільшити покриття за допомогою ШІ; Справжня цінність полягає в написанні значущих очікувань. Цінність тесту полягає в його здатності зламати та сповіщати вас, коли код зламано. Ось чому тести, згенеровані штучним інтелектом, базуються на питанні «чи дійсно код ламається, коли він змінюється?» Перевірте це за допомогою запитання; Навмисний розрив рядка та побачення розриву тесту (ідея мутації) є доказом того, що тест спрацював.
Порада: щоб перевірити, чи працює тест, створений штучним інтелектом, створіть невелику помилку в коді (наприклад, змініть + на -) і подивіться, чи не вийде тест. Якщо він не зламався, цей тест вас не захищає.
Поширені помилки
- Запит на тест без надання правила. Модель заморожує поточну поведінку; виправляє помилку як "true".
- Прийняття очікувань, не читаючи їх. Тестування вводить в оману, якщо ви не перевіряєте, чи твердження перевіряють правильне значення.
- Просто випробування щасливого шляху. Реальні помилки живуть на полях; Явно запитуйте крайні випадки.
- Помилково сприймаючи сферу дії з метою. Високий відсоток не є гарантією правильної поведінки.
- Створення реальних/прихованих даних як тестових даних. Дані або секрети клієнтів не повинні проходити тестування та зберігатися; Генерувати синтетичні дані.
Підсумовуючи
ШІ знімає значну частину повторюваного тягаря написання тестів: він створює швидкі скелети, великі списки граничних випадків і аналізи прогалин у охопленні. Але найбільш критичним моментом є очікування: штучний інтелект має тенденцію тестувати поточну поведінку коду, тоді як тестування має бути написано відповідно до специфікації. Надайте правило, перевірте очікування, застосуйте граничні випадки та перевірте, чи дійсно тести захищають шляхом впровадження помилки. Тестове покриття – це інструмент, а не мета.
Аплікаційне завдання
Виберіть функцію та спочатку надрукуйте тест на AI, просто вказавши її код; Зверніть увагу на очікування. Потім знову роздрукуйте тест, надавши специфікацію (необхідну поведінку) для тієї ж функції. Порівняйте очікування від двох наборів тестів: чи є якісь відмінності, який із них виявляє справжню помилку? Нарешті, переконайтеся, що один із згенерованих тестів спрацював, додавши навмисну помилку до коду та побачивши зрив тесту.
контрольний список
- [ ] Я розрізняю, чи є тест для виправлення чи перевірки поведінки.
- [ ] Коли я запитую тест, я надаю правило (специфікацію), яке має бути на місці, а не код.
- [ ] Я порівнюю кожне згенероване твердження зі специфікацією.
- [ ] Я прямо прошу крайні випадки та випадки відмови.
- [ ] Я розглядаю відсоткове покриття як інструмент, а не як ціль.
- [ ] Я перевіряю, чи дійсно тест захищає, вводячи помилки.