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