Добици:
- Способност израде тестирања јединица, ивичних случајева и анализе јаза у покривености помоћу АИ
- Могућност штампања тестних очекивања на основу спецификације, а не тренутног понашања кода
- Способност тестирања да ли тест заиста штити убацивањем грешака
Писање тестова је један од задатака који највише производе вредност који већина програмера одлаже. Добар тест пакет је доказ да код ради како се очекује и спас за будуће промене. Проблем је у томе што је писање тестова понављајуће и дуготрајно – управо она врста посла у којој блиста вештачка интелигенција. Али постоји квака: АИ често тестира постојеће понашање кода, а не понашање какво би требало да буде. Управљање овом разликом је суштина ове јединице.
У овој јединици ћете научити тестирање јединица (тестирање које тестира само функцију, изоловано), тестове ивица и генерисање тестних података помоћу АИ; затварање празнина у покривености тестом; и зашто је слепо веровати тестовима вештачке интелигенције опасно.
Две стране тестирања: поправљање понашања наспрам верификације
Тест може служити у две различите сврхе. Прва је верификација: она тестира да ли је код исправан, да ли је у складу са спецификацијом. Друга је заштита од регресије: замрзава понашање кода данас, па ако га неко случајно промени сутра, тест ће покварити и обавестити.
АИ је веома добар у овом последњем; Гледа код и генерише случајеве који тестирају „шта тренутно ради“. Али ако је код погрешан од самог почетка, АИ може то погрешно понашање означити као „тачно“. Дакле, морате прегледати тврдњу сваког теста који АИ произведе: „Код враћа 42, а тест очекује 42“ не значи да је 42 тачан одговор.
Опрез: Ако АИ прође тест, то не значи да код „ради“; то само значи "понаша се како АИ очекује". Ви одлучујете да ли је очекивање тачно или не гледајући спецификацију.
Корак по корак: Писање робусних тестова са АИ
- Дајте спецификацију, а не само код. Ако додате информацију „Ова функција треба да уради ово“, АИ може да напише тачно очекивање; Тестираће тренутно понашање ако само унесете код.
- Питајте за рубне случајеве. Празан, нула, нула, негативан, превелик, лош формат, истовременост — експлицитно тврдите да сте ван срећног пута.
- Одредите оквир и стил тестирања. „користи питест“, „Уреди-Делуј-Асерт образац“, „нека сваки тест тестира једну ствар“ итд.
- Проверите очекивања (тврдња). Упоредите са спецификацијом коју свако тврдње проверава да ли је тачна вредност.
- Затворите празнине у обиму. Дајте постојеће тестове и питајте "које гране и случајеви нису тестирани?" натерати вас да питате; затим верификовати направљене додатне тестове.
Три мини кућишта
Случај 1 — Покривеност од 52% до 85%. Покривеност тестом једног сервисног модула била је 52%. Тим је дао постојеће тестове вештачкој интелигенцији, дао јој листу нетестираних грана и генерисао тестове за њих. Са људским прегледом, покривеност је порасла на 85%; У том процесу, АИ је открио стварну грешку (пут који је вратио погрешан код грешке) у грани грешке која никада раније није била тестирана.
Случај 2 — Замка фиксирања лажних очекивања. Функција заокруживања новца је заправо била погрешна; Уместо заокруживања 2,675 на 2,67, заокружило се 2,67 уместо 2,68. АИ је погледао код и написао ассерт роунд_монеи(2.675) == 2.67 — замрзавајући грешку као „тачно“. Када је програмер прочитао спецификацију, исправио је очекивање и ухватио праву грешку. Тестирање правила, а не кода, направило је разлику.
Случај 3 — Експлозија рубног стања. Када се од АИ тражи само „ивичне случајеве“ за функцију распона датума; Произвео је 8 случајева као што су почетак=крај, обрнути интервал, преступна година 29. фебруар, различите временске зоне и нулти интервал. Две од њих (обрнути размак и преступна година) су заправо узроковале грешку. Ручно разматрање ових случајева се често прескаче; АИ је овде постао партнер у „ивичним размишљањима“.
Четири шаблона за копирање
Генерисање тестова на основу спецификација:
Улога: Програмер који пише тестове. Оквир: {{питест/ЈУнит/Јест...}}. Шта функција ТРЕБА ДА РАДИ (спецификација): {{руле}}Напишите тестове за следећу функцију. Напишите очекивања према спецификацији, а НЕ тренутни излаз кода. Срећан пут + додајте најмање 4 рубна случаја. Нека сваки тест тестира једну ствар, користите описно име. {{функција}}
Размишљање о крајњим случајевима:
Наведите случајеве ивице/неуспеха које треба испробати у тестирању ове функције (нулл, нулл, тачке прекида, лош формат, конкурентност, спољна грешка). За сваки случај: унос, очекивано понашање. НЕ пишите још код, само наведите.{{функција}}
Анализа јаза у покривености:
Испод су функције и доступни тестови. Које гране, услови и случајеви нису тестирани? Наведите недостатке и напишите нове тестове само за недостатке. Немојте понављати постојеће. Функција:{{фунцтион}}Тестови:{{екистинг_тестс}}
Тест подаци / генерисање лажног објекта:
Генеришите реалистичне тестне податке за {{фунцтион/сервице}} тестове: важеће узорке, узорке граница и неважеће узорке одвојено. Предложите једноставно лажно понашање за спољну зависност {{Кс}}. Коришћење истинитих поверљивих података/ПИИ; Генеришите лажне податке.
Слаби промпт / Јаки промпт
Слабо: "Напишите тест за ову функцију."
Снажно: „са питестом. Функција аппли_дисцоунт(тотал, проценат) — правило: попуст мора бити 0%–30%, ван граница треба да избаци ВалуеЕррор, резултат треба заокружити на 2 децимале. Очекивања напишите према овом ПРАВИЛУ (не по коду). Сретан пут + ови случајеви ивице: 0%, 30%, или 31% негативан код, [укупни код]
Он даје правило снажног ослобађања и каже „напишите очекивање према правилу, а не коду“; Ова једина реченица затвара замку АИ поправљања лошег понашања.
Тип теста
АИ допринос
људска контрола
Срећно тестирање јединице на путу
брзи скелет
Да ли је очекивање тачно?
Едге цасе
Екстензивно размишљање
Елиминишите небитно
Попуњавање празнина у обиму
Проналази прескочене гране
Потврдите значај
Тест података/моцк
Ствара реалан узорак
Нема ПИИ, контрола реализма
Тестови управљају квалитетом, а не гарантују
Висока покривеност тестом даје самопоуздање, али такође може да завара: 100 одсто покривености значи „свака линија је покренута“, а не „свака линија је тачна“. Лако је повећати покривеност помоћу АИ; Права вредност је у писању смислених очекивања. Вредност теста је његова способност да разбије и упозори вас када је код покварен. Зато се тестови генерисани од вештачке интелигенције заснивају на питању „да ли се код заиста поквари када се промени?“ Тестирајте га питањем; Намерно прекидање линије и виђење прекида теста (идеја о мутацији) доказ је да је тест успео.
Савет: Да бисте видели да ли тест који АИ пише ради, направите малу грешку у коду (нпр. промените + у -) и видите да ли се тест поквари. Ако се не поквари, тај тест вас не штити.
Уобичајене грешке
- Тражите тест без давања правила. Модел замрзава тренутно понашање; поправља грешку као "тачно".
- Прихватање очекивања без читања. Тестирање је погрешно ако не проверите да ли тврдње проверавају тачну вредност.
- Само тестирам срећан пут. Праве грешке живе на маргинама; Експлицитно затражите рубне случајеве.
- Грешка обима за сврху. Висок проценат није гаранција исправног понашања.
- Прављење стварних/скривених података као тест података. Подаци о клијентима или тајне не би требало да улазе у тестирање и складиштење; Генеришите синтетичке податке.
Укратко
АИ преузима велики део терета који се понавља са писањем тестова: производи брзе костуре, велике листе ивичних случајева и анализе јаза у покривености. Али најкритичнија тачка су очекивања: АИ тежи да тестира тренутно понашање кода, док тестирање треба да буде написано у складу са спецификацијом. Дајте правило, проверите очекивања, примените рубне случајеве и тестирајте да ли тестови заиста штите убацивањем грешке. Покривеност тестом је средство, а не циљ.
Задатак апликације
Изаберите функцију и прво одштампајте тест на АИ једноставним давањем њеног кода; Обратите пажњу на очекивања. Затим поново одштампајте тест, дајући спецификацију (потребно понашање) за исту функцију. Упоредите очекивања два скупа тестова: да ли постоје различити, који открива праву грешку? На крају, проверите да ли је један од генерисаних тестова функционисао додавањем намерне грешке у код и гледањем прекида теста.
контролна листа
- [ ] Разликујем да ли је тест да поправи или потврди понашање.
- [ ] Када захтевам тест, дајем правило (спецификацију) које треба да буде на месту, а не код.
- [ ] Упоређујем сваку генерисану тврдњу са спецификацијом.
- [ ] Експлицитно захтевам ивице и случајеве неуспеха.
- [ ] Процентуално покривање посматрам као средство, а не циљ.
- [ ] Тестирам да ли тест заиста штити убацивањем грешака.