Прибуток:
- Здатність проводити модульні, інтеграційні та граничні тести зі змістовним твердженням за допомогою ШІ
- Можливість систематично отримувати тестове покриття, граничні значення та негативні сценарії за допомогою штучного інтелекту
- Можливість перевірити, чи тести, створені штучним інтелектом, дійсно перевіряють поведінку, а не просто повторюють існуючий код
Тестування — це механізм, який доводить, що програмне забезпечення справді поводиться так, як було обіцяно. Хороший набір тестів за лічені секунди повідомляє вам, чи зміна щось порушує, і дає інженеру свободу діяти впевнено. AI прискорює найнуднішу та найбільш пропускану частину написання тесту: генерує безліч сценаріїв, контрольних точок і негативних випадків. Але тут є підступна пастка: ШІ може писати тести, які перевіряють поточну (можливо, помилкову) поведінку коду, а не його передбачувану поведінку; або він може створювати порожні тести, які завжди проходять, фактично нічого не перевіряючи. Цінність тесту полягає не в тому, чи він пройдений, а в тому, чи він перевіряє правильну річ і стає червоним, коли вона неправильна.
У цьому розділі ви навчитеся створювати одиничні, інтеграційні та крайові тести зі змістовними твердженнями; як систематично отримувати тестове покриття, точки зупинки та негативні сценарії; і ми побачимо, як ви можете перевірити, що тести, які проводить AI, дійсно підтверджують поведінку.
Концепції: модульне тестування: тестує одну функцію/клас ізольовано. Тестування інтеграції: перевіряє, чи правильно працюють разом кілька частин. Assert: оператор, який перевіряє, чи результат дорівнює очікуваному; Це суть тесту. Покриття: яка частина коду виконується тестами; Висока покриваність не гарантує якості.
Виготовлення значущих тестів
Хороший тест чітко робить три речі: він встановлює стан, він виконує дію, він підтверджує результат. Під час друкування тестів у ШІ вкажіть, яку поведінку ви хочете перевірити та які сценарії вона має охоплювати; Інакше він створює поверхневі тести, які завжди проходять.
- Визначте поведінку, яку потрібно перевірити. «Що вважається правильним?» Дайте чітку відповідь на запитання.
- Запитайте типи сценаріїв. Нормальний, граничний, негативний, стан помилки.
- Імпорт осмисленого твердження. Це не просто «викинуло помилку», воно «повернуло правильне значення».
- Перевірте точність тесту. Тест стає червоним, коли ви свідомо зламуєте код?
Підказка щодо генерації комплексного тесту: «Напишіть одиничні тести для такої функції «applydiscount(сума, купон)». Майте ПРИМЕНШЕ один сценарій у таких категоріях: (1) звичайний дійсний купон, (2) контрольні точки (0 сума, 100% знижка), (3) негативний (недійсний купон, від’ємна сума), (4) випадок помилки (нульовий купон). Стверджуйте очікуване значення CONCRETE у кожен тест (а не просто "працював").
Підказка щодо вилучення граничного значення: «Виконайте аналіз граничного значення для вхідних даних цієї функції. Для кожного параметра витягніть значення «тільки на межі», «трохи нижче межі», «трохи над межею» у вигляді таблиці. Потім перелічіть тестові сценарії, які охоплюють ці межі. Поки що не пишіть код, лише аналіз і список сценаріїв. Функція: [підпис]»
Застереження: Високе покриття тесту (наприклад, 90%) не доводить, що код правильний. Покриття вимірює, скільки рядків було виконано; не те, що ці рядки дають правильний результат. Тест без значущого твердження збільшує охоплення, але нічого не гарантує. Зміст заяви визначає якість, а не кількість тверджень.
Тестування самого тесту: логіка мутації
Найпрактичніший спосіб зрозуміти, чи справді працює тест, створений штучним інтелектом, — це навмисно зламати код (логіка тестування на мутації). Змінити умову, поставити знак + -; Якщо жоден тест не стане червоним, ваші тести насправді не зберігають таку поведінку.
Підказка перевірки вразливості: «Скажіть мені, які потенційні помилки в цьому коді МОЖУТЬ НЕ виявити наступні тести. Запропонуйте 5 невеликих змін, які можна внести в код (наприклад, >= замість >, - замість +) і вкажіть для кожної з них, чи зможуть існуючі тести виявити її. Для тих, хто не виявив, запропонуйте тестування, яке слід додати. Код: [код] Тести: [тест]»
Слабка підказка / Сильна підказка
WEAK: "Напишіть тест для цієї функції." (Результат: зазвичай один вдалий сценарій, слабке твердження; пропускає помилки.) СИЛЬНИЙ: «Напишіть тест для цієї функції «passwordStrong». Правило: потрібно принаймні 8 символів, 1 велика літера, 1 цифра. Охопіть наступні сценарії як ОКРЕМІ тести: рівно 8 символів (ліміт), 7 символів (нижче ліміту), без великих літер, без цифр, порожній рядок, також лише пробіли. довгий (1000 символів) Явно підтвердьте очікуване значення true/false у кожному тесті та назвіть тест відповідно до того, що він перевіряє."
Потужна підказка надає правила та повні граничні сценарії. Обмежувальні пари, як-от "рівно 8/7 символів", є найпоширенішими місцями помилок (плутаючи > з >=). Слабка підказка обходить ці межі та переносить помилку у виробництво.
Типи тестів і де використовувати
Тип тесту
Що це підтверджує?
внесок ШІ
Увага
одиниця
Одна функція/клас
Швидко створює кілька сценаріїв
Потрібне значуще твердження
інтеграція
Частини, що працюють разом
Сценарій і макет чернетки даних
Справжня адиктивна поведінка
закінчити/прийняти
Весь потік користувачів
Список кроків і очікування
схильні до ламкості
регресія
Стара помилка не повертається
Тестування на конкретні несправності
Слід додати до кожного виправлення
Міні-чохли
Випадок 1 — Тест, який завжди проходить. ШІ пише 12 тестів для функції, і всі вони проходять. Інженер стає підозрілим і навмисно спотворює значення, що повертається функцією; Лише 3 тести стають червоними. Інші 9 тестів не містять значущих тверджень. Тестування посилюється пошуком мутацій; реальний захист досягається за 9 сценаріями.
Випадок 2 — помилка межі. Функція перевірки віку має містити повідомлення «18 і старше — дійсне», але написано >18, тобто вік 18 років відхиляється. Помилка виявляється відразу під час тестування, оскільки AI генерує сценарій «рівно 18» за допомогою аналізу точки зупину. Єдиний лімітний тест запобігає будь-яким реальним користувачам.
Випадок 3 — Виправлення поточної поведінки. Коли ШІ кажуть «написати тест на основі цього коду», він створює тест, який приймає як «правильну» помилку округлення, яка вже існує в коді. Коли інженер друкує тест відповідно до вимог (очікуваного правильного значення), а не коду, тест стає червоним і виникає справжня помилка. Тести повинні бути отримані з очікувань, а не з коду.
Поширені помилки
- Безглуздо твердження. «Не видав помилку» недостатньо; Необхідно перевірити правильне значення.
- Плутання обсягу з якістю. Високе покриття не є гарантією точних результатів.
- Друк тесту за кодом. Виправляє поточну помилку на «true»; Тести повинні випливати з очікувань.
- Пропуск граничних значень. Плутання > з >= є найпоширенішою помилкою; граничні пари повинні бути перевірені.
- Не перевіряючи сам тест. Тест, який не стає червоним при зломі коду, не забезпечує захисту.
Підсумовуючи
Хороший набір тестів є ключем до впевненого внесення змін. ШІ швидко генерує безліч сценаріїв, обмежень і негативних ситуацій; Але якщо він отримує тести з коду, а не з вимог, він може виправляти наявні помилки або писати безглузді тести, які завжди проходять. Стверджуйте конкретне очікуване значення в кожному тесті, включайте зв’язані пари та перевіряйте, чи дійсно ваші тести захищають шляхом навмисного порушення коду. Зміст твердження, а не кількість областей, визначає якість.
Аплікаційне завдання
Виберіть функцію та згенеруйте тести в чотирьох категоріях (нормальний, граничний, негативний, помилковий) із підказкою для створення комплексного тесту; Отримайте конкретне очікуване значення в кожному тесті. Потім запустіть запит на пошук уразливостей, запропонуйте 5 невеликих мутацій у коді та запустіть тести, щоб перевірити, які з них вони вловлюють. Додайте новий тест принаймні на одну мутацію, яка не була виявлена, і покажіть, що вона зараз у мінусі.
контрольний список
- [ ] Я надрукував тести на основі очікуваної/правильної поведінки, а не коду.
- [ ] Я розглянув нормальний, граничний, негативний і помилковий сценарії.
- [ ] Я стверджував конкретне очікуване значення в кожному тесті.
- [ ] Я тестував пари кордонів (трохи вище-нижче / трохи вище-нижче).
- [ ] Навмисно зламавши код, я підтвердив, що тести стали червоними.
- [ ] Я додав новий тест на невиявлені мутації.