Добивки:
- Способност да се спречи вештачката интелигенција да го прифати погрешното однесување како „точно“ со пресметување на очекуваната вредност во единечните тестови независно од правилото за прифаќање
- Способност за печатење брзи, независни и повторливи тестови со примена на принципите AAA и FIRST и исмевање на надворешните зависности
- Способност да се тестираат тестови со мутација (кршење на кодот) и да се препознае кодот кој тешко се тестира како мирис на дизајн
Најголемиот и најбрзиот слој на пирамидата за тестирање е единечно тестирање - тестирање што потврдува функција или мал дел од кодот изолирано од сè друго. Илјадници единечни тестови се извршуваат за секунди и фаќаат грешка додека кодот е сè уште на екранот на развивачот. Вештачката интелигенција (ВИ) е можеби најмногу умешна во производството на единечни тестови: вие и давате функција, вештачката интелигенција произведува десетици тестови. Но, токму оваа погодност предизвикува најголемата замка: ВИ лесно произведува тестови кои „светат зелено, но не потврдуваат ништо“ или го прифаќаат моменталното (можеби неисправно) однесување на кодот како „точно“. Во оваа единица ќе научите како да пишувате тестови за вистински заштитни единици со вештачка интелигенција и врската помеѓу кодот што може да се тестира и вештачката интелигенција.
Квалитети на добар тест за единица: ПРВО
Добрите единечни тестови ги следат ПРВИТЕ принципи: Брзи, Независни (тестовите не треба да зависат еден од друг), Повторливи (повторливи - ист резултат во која било средина), Самопотврден (јасно поминување/неуспешно), Навремено (навреме). Потсетете се на овие принципи кога правите тестови за производство на вештачка интелигенција; конкретно побарајте тестот да не зависи од надворешниот свет (вистинската база на податоци, мрежа, часовник) да биде „независен“ и „повторлив“.
ААА шема и експресивен тврдење
Тест со солидна единица ја следи структурата AAA: Распоредете (подгответе - поставете влезови и зависности), Act (изврши - повикајте ја функцијата што се тестира), Потврдете (валидирајте - споредете го резултатот со очекуваната вредност). Критичното е тврдење. Најчеста грешка што ја прави вештачката интелигенција е изведувањето на тврдењето од излезот на кодот што се тестира - логиката „што и да враќа кодот е точно“. Ова го прави тестот бесмислен. Точниот начин е самостојно да се одреди очекуваната вредност (од критериумите за прифаќање, пресметајте ја рачно).
Внимание: Ако на ВИ кажете „напишете тест за оваа функција“, вештачката интелигенција може да ја изврши функцијата и да го напише нејзиниот излез како „очекуван“. Овој тест поминува дури и ако функцијата е лажна. Наместо тоа, кажете „ги пресметувате очекуваните резултати според овие правила, не упатувајте на тековниот излез на функцијата“.
Исмејувања, никулци и зависности
Единицата за тестирање бара изолација. Ако вашата функција зависи од базата на податоци или API, тие се заменуваат со лажни објекти (смевање/никулец — контролирана, лажна замена за вистинската зависност) при тестирањето. Ова го прави тестот брз, независен и репродуктивен. ВИ може да произведе лажна инсталација; Но, пазете се од прекумерно исмејување: ако се потсмевате на сè, тестот само ќе потврди „што враќа подбивањето“, а не вистинската логика. Баланс: емулирајте го надворешниот свет, извршете ја вистинската логика што се тестира.
Тестибилност и вештачка интелигенција
Има интересна повратна информација: кодот што е тешко да се тестира често е лошо дизајниран код. Ако вештачката интелигенција има проблеми со пишување тестови за некоја функција (премногу зависности, скриена глобална состојба, несакани ефекти), тоа е мирис на дизајн. Прашањето на вештачката интелигенција „како би го рефакторирале овој код за да може да се тестира“ води до подобро тестирање и подобар код.
Параметризирани тестови и разновидност на податоци
Пишувањето посебен тест секој пат за да се потврди истото правило со различни влезови е и досадно и тешко за одржување. Параметризирано тестирање - структура која постојано ја извршува истата тест логика на списокот на влезови и очекувани резултати - го елиминира ова повторување: едно тело за тестирање се напојува со десетици влезни парови. Вештачката интелигенција е многу ефикасна во создавањето на овие табели со исходи што се очекуваат од влезните податоци кога ќе и ги дадете вашите правила за прифаќање; Особено, тој систематски ги табелира граничните вредности и класите на еквивалентност.
Но, тука има и замка: ВИ има тенденција да ги изведе очекуваните резултати во генерираната табела од кодот што се тестира. Оваа грешка е уште поопасна при параметрирано тестирање, бидејќи една неточна логика поништува десетици линии. Затоа, колоната за очекуваниот резултат секогаш нека се пресметува независно според правилото за прифаќање и рачно потврдувајте барем неколку редови. Побарајте и колона за опис „што претставува секој ред“; па кога ќе се прекине редот, веднаш гледате која состојба е скршена.
Совет: Намерно додајте „ред за стапица“ на параметризирана тест табела - односно свесно погрешно напишете го резултатот. Ако таа линија не стане црвена кога ќе го извршите тестот, вашиот тест всушност не ја потврдува таа ситуација. Ова е брза проверка на лажни пропусници.
Слаб промпт / Силен промпт
Слабо: „Напишете тест за единица за оваа функција“.
Силно: напишете тестови за единица [јазик/рамка] за функцијата "taxCalculate(amount, rate). Правило за прифаќање: резултат = износ * стапка, заокружена на 2 децимали; негативната сума или стапката фрла грешка; враќа 0 ако стапката е 0. Користете структура AAA. Рачно пресметајте ги очекуваните вредности според ОВИЕ правила; Голем, круг до децимали Нека името на секој тест го опишува правилото што го потврдува „Не“.
Моќен потсетник; Го дава правилото за прифаќање, независните очекувања за очекуваната вредност, структурата и рабовите случаи. Така, тестот станува чувар на правилото, а не огледало на кодот.
Табела за квалитет на тест за единица
симптом
Лош тест (лажна доверба)
добар тест
тврдат
Нема или „не е нула“
Очекувана конкретна вредност
Очекуван извор на вредност
Излез од функцијата
Правило за прифаќање / рачна пресметка
зависност
Вистински DB/мрежа/час
Изолиран со потсмев/никулец
раб куќиште
Само среќен пат
граница, негативна, грешка
Кога ќе го прекршите кодот
останува зелена
станува црвено
Име
тест1, тестМетод
го опишува правилото што го потврдува
Четири шаблони за копирање
1) Тестирање единица управувана од правила:
Вашата улога: виш инженер за тестирање на софтвер. Напишете единечен тест за следнава функција со [јазик/рамка]: [потпис]. Правила за прифаќање: [правила].- Користете структура ААА.- Рачно пресметајте ги очекуваните вредности според ОВИЕ правила; НЕ повикувајте на тековниот излез на функцијата. - Покријте ја границата, негативната, грешката и среќната патека со посебни тестови. - Секое име на тестот нека го опише правилото што го потврдува. - Исмејување на надворешните зависности; Направете ја вистинската логика да функционира.
2) Контрола на отпорност на мутации:
Проверете ги овие тестови на единицата. Наведете 5 помали измени што би можел да ги направам во кодот што се тестира (a - наместо +, a >= наместо >, поместување на границата) и кажете ми за секој КОЈ од овие тестови ќе стане црвено? Ако ниту еден не се врати, тестот е недоволен. Код + тестови: [залепи]
3) Преглед на способност за тестирање:
Зошто е тешко да се напише единица тест за оваа функција? Скриена зависност, глобален статус, несакани ефекти, има ли многу обврски? Предложете минимално рефакторирање за да може да се тестира; не го менувајте однесувањето. Код: [залепи]
4) Нецелосно завршување на сценариото:
Дадени се следната функција и достапни тестови. Наведете кое однесување/работно дело НИКОГАШ не било тестирано (јаз во опсегот) и додајте тест за секоја од нив. Функција + тестови: [залепи]
три мини футроли
Случај 1 - Тест за пресликување на кодот. Еден програмер побара од AI да напише тест за функцијата за заокружување; 10 тестови беа зелени. Всушност, функцијата се заокружуваше во погрешна насока, но вештачката интелигенција ги зеде очекуваните вредности од излезот на функцијата, па тестовите ја сметаа грешката за „вистинита“. Кога очекуваните вредности беа рачно пресметани со шаблонот „управувано од правила“, 4 тестови станаа црвени и беше откриена вистинската грешка.
Случај 2 - Вредноста на контролата на мутациите. Еден тим се потпираше на 45 единечни тестови. Испробав 20 помали измени на кодот со „проверка на издржливост на мутација“; тестовите фатија само 11 од нив. Останатите 9 прекини поминаа тивко. Тимот ги засили слабите тестови; Вистинската грешка во пресметката беше фатена од овие подобрени тестови во следното издание.
Случај 3 - Непроверливоста е мирис на дизајн. Вештачката интелигенција не можеше да пишува тестови за функцијата за нарачка, постојано ѝ требаше вистинската база на податоци. Шаблонот „преглед за тестирање“ покажа дека функцијата го вградува пристапот до базата на податоци. Кога ќе се отстрани инјекцијата за зависност, можеше да се напишат тестови и кодот стана почист.
Вообичаени грешки
- Изведување на очекуваната вредност од кодот. AI го прифаќа излезот на функцијата како „точен“; тест кој потврдува погрешен код.
- Тест без тврдење или со тривијално тврдење. „Не уфрли грешка, помина“ логика; Ништо не потврдува.
- Екстремна потсмев. Исмејување на сè и тестирање само на она што го враќа потсмевот; вистинската логика не се тестира.
- Само среќен пат. Заобиколувајќи ги граничните, негативните и состојбите на грешка.
- Не се тестира со кршење на кодот. Доверба на зелена боја без проверка на мутација.
- Игнорирање на непроверливост. Не препознавање и поправка на лошиот дизајн наместо напорно тестирање.
Сумирано
Единечните тестови се најбрзиот и најголемиот слој на пирамидата за тестирање; Ја фаќа грешката во најевтиниот момент. Вештачката интелигенција е многу способна да произведува единечни тестови, но нејзината најголема замка е пишувањето тестови кои претпоставуваат неправилно однесување како „точно“ со изведување на очекуваната вредност од самиот код. Решение: дајте ги правилата за прифаќање, рачно пресметајте ги очекуваните вредности, спроведете ги принципите AAA и FIRST, исмејувајте се со надворешниот свет и извршете ја вистинската логика и тестирајте го секој тест со мутација (кршење на кодот). Кодот што е тешко да се тестира е дизајнерски знак што треба да се поправи.
Задача за апликација
Изберете функција која содржи деловно правило од вашиот сопствен проект. Напишете правила за прифаќање и нека вештачката интелигенција пишува тестови со шаблонот „Тестирање на единицата управувана од правила“; Нека ги пресметаат очекуваните вредности рачно. Потоа применете ја „проверката на робусноста на мутацијата“: направете најмалку 5 мали прекини во кодот и измерете колку тестови стануваат црвени. Додадете нов тест за неоткриени корупции. Пријавете колку прекини се фатени (како што е резултат на мутација).
листа за проверка
- [ ] Ги дадов правилата за прифаќање и ги пресметав очекуваните вредности рачно.
- [ ] Се уверив дека тестовите не ја извлекуваат очекуваната вредност од кодот.
- [ ] Имам воспоставено независно тестирање следејќи ги упатствата AAA и FIRST.
- [ ] Ги исмевав надворешните зависности и ја водев вистинската логика.
- [ ] Покрив лимит, негативни и случаи на грешки.
- [ ] Со кршење на кодот (мутација) докажав дека тестовите навистина штитат.