Pelnas:
- Galimybė neleisti dirbtiniam intelektui priimti klaidingą elgesį kaip „teisingą“, apskaičiuojant numatomą vertę vieneto testuose nepriklausomai nuo priėmimo taisyklės
- Galimybė spausdinti greitus, nepriklausomus ir kartojamus testus, taikant AAA ir FIRST principus ir tyčiojantis iš išorinių priklausomybių
- Gebėjimas išbandyti testus su mutacija (kodo laužymu) ir atpažinti sunkiai patikrinamą kodą kaip dizaino kvapą
Didžiausias ir greičiausias testavimo piramidės sluoksnis yra vienetinis testavimas – testavimas, kuris patikrina funkciją arba nedidelę kodo dalį atskirai nuo visko. Tūkstančiai vienetų testų atliekami per kelias sekundes ir aptinka klaidą, kol kodas vis dar rodomas kūrėjo ekrane. Dirbtinis intelektas (AI) yra bene labiausiai įgudęs atlikti vienetinius testus: jūs suteikiate jam funkciją, AI sukuria daugybę testų. Tačiau būtent šis patogumas sukelia didžiausius spąstus: AI lengvai sukuria testus, kurie „šviečia žaliai, bet nieko nepatvirtina“ arba priima dabartinį (galbūt klaidingą) kodo elgesį kaip „teisingą“. Šiame skyriuje sužinosite, kaip parašyti tikrai apsauginius vienetų testus naudojant AI ir apie ryšį tarp tikrinamo kodo ir AI.
Gero vieneto testo savybės: PIRMA
Geri vienetiniai testai atitinka FIRST principus: Greitas, Nepriklausomas (testai neturi priklausyti vienas nuo kito), Pakartojamas (pasikartojamas – tas pats rezultatas bet kokioje aplinkoje), Savaiminis patvirtinimas (aiškus patvirtinimas/nepatikimas), Laiku (laiku). Priminkite sau šiuos principus, kai AI gamina testus; konkrečiai paprašykite, kad testas nepriklausytų nuo išorinio pasaulio (faktinės duomenų bazės, tinklo, laikrodžio), kad būtų „nepriklausomas“ ir „pakartojamas“.
AAA raštas ir išraiškingas tvirtinimas
Kietojo vieneto testas atitinka AAA struktūrą: Išdėstyti (paruošti – nustatyti įvestis ir priklausomybes), veikti (vykdyti – iškviesti bandomą funkciją), Patvirtinti (patvirtinti – palyginti rezultatą su numatoma reikšme). Kritinis yra tvirtinimas. Dažniausia AI daroma klaida yra teiginio išvedimas iš bandomojo kodo išvesties – logikos „viską, ką grąžina kodas, yra tiesa“. Dėl to testas tampa beprasmis. Teisingas būdas yra savarankiškai nustatyti numatomą vertę (pagal priėmimo kriterijus apskaičiuokite ją rankiniu būdu).
Dėmesio: jei pasakysite AI „parašyti šios funkcijos testą“, AI gali paleisti funkciją ir parašyti jos išvestį kaip „tikėtiną“. Šis testas išlaikomas, net jei funkcija klaidinga. Vietoj to pasakykite: „Jūs apskaičiuojate laukiamus rezultatus pagal šias taisykles, nenurodykite esamos funkcijos išvesties“.
Pasityčiojimas, stulbinimas ir priklausomybės
Vieneto bandymas reikalauja izoliacijos. Jei jūsų funkcija priklauso nuo duomenų bazės arba API, testuojant jie pakeičiami netikrais objektais (mock/stub – kontroliuojamas, netikras tikrosios priklausomybės pakaitalas). Dėl to testas yra greitas, nepriklausomas ir atkuriamas. AI gali sukurti netikrą instaliaciją; Tačiau saugokitės besaikio tyčiojimosi: jei tyčiositės iš visko, testas patikrins tik tai, „ką pajuoka grąžina“, o ne tikrąją logiką. Balansas: mėgdžiokite išorinį pasaulį, vykdykite tikrąją testuojamą logiką.
Bandomumas ir AI
Yra įdomus atsiliepimas: kodas, kurį sunku išbandyti, dažnai yra prastai sukurtas kodas. Jei dirbtinis intelektas turi problemų rašant funkcijos testus (per daug priklausomybių, paslėpta pasaulinė būsena, šalutinis poveikis), tai yra dizaino kvapas. Paklausus AI „kaip pakeistumėte šį kodą, kad jį būtų galima išbandyti“, bus geresnis testavimas ir geresnis kodas.
Parametrizuoti testai ir duomenų įvairovė
Kiekvieną kartą rašyti atskirą testą, kad būtų galima patikrinti tą pačią taisyklę naudojant skirtingus įvesties duomenis, yra varginantis ir sunku jį prižiūrėti. Parametrizuotas testavimas – struktūra, kuri pakartotinai atlieka tą pačią bandymo logiką įvesties ir laukiamų rezultatų sąraše – pašalina šį pasikartojimą: vienas bandomasis korpusas maitinamas dešimtimis įvesties porų. AI labai efektyviai sukuria šias įvesties laukiamų rezultatų lenteles, kai pateikiate jai savo priėmimo taisykles; Visų pirma jame sistemingai pateikiamos ribinės vertės ir lygiavertiškumo klasės.
Tačiau čia taip pat yra spąstai: AI yra linkusi gauti laukiamus rezultatus sugeneruotoje lentelėje iš bandomojo kodo. Ši klaida yra dar pavojingesnė atliekant parametrizuotą testavimą, nes viena neteisinga logika panaikina dešimtis eilučių. Todėl visada pasirūpinkite, kad laukiamo rezultato stulpelis būtų apskaičiuotas nepriklausomai pagal priėmimo taisyklę ir rankiniu būdu patvirtintų bent kelias eilutes. Taip pat paprašykite aprašymo stulpelio „ką reiškia kiekviena eilutė“; taigi, kai eilutė nutrūksta, iš karto matote, kuri būsena nutrūkusi.
Patarimas: tyčia pridėkite „spąstų eilutę“ į parametrizuotą bandymo lentelę – tai yra, sąmoningai klaidingai įvedėte rezultatą. Jei ta eilutė nepasidaro raudona, kai atliekate testą, jūsų testas iš tikrųjų nepatvirtina tos situacijos. Tai greitas bandomasis patikrinimas.
Silpnas raginimas / Stiprus raginimas
Silpnas: „Parašykite šios funkcijos vieneto testą“.
Stiprus: parašykite [kalbos/sistemos] vieneto testus funkcijai "taxCalculate(summa, norma). Priėmimo taisyklė: rezultatas = suma * rodiklis, suapvalintas iki 2 dešimtųjų; neigiama suma arba rodiklis pateikia klaidą; grąžina 0, jei rodiklis yra 0. Naudokite AAA struktūrą. Rankiniu būdu apskaičiuokite laukiamas reikšmes pagal ŠIAS taisykles; nenurodykite didelės neigiamos funkcijos atvejų. po kablelio). Tegul kiekvieno testo pavadinimas apibūdina taisyklę, kurią jis patikrina.
Galingas raginimas; Ji pateikia priėmimo taisyklę, nepriklausomą tikėtinos vertės lūkesčius, struktūrą ir kraštutinius atvejus. Taigi testas tampa taisyklės sergėtoju, o ne kodo veidrodžiu.
Vieneto bandymo kokybės lentelė
simptomas
Blogas testas (netikras pasitikėjimas)
geras testas
tvirtinti
Nėra arba „ne null“
Numatoma konkreti vertė
Numatomas vertės šaltinis
Funkcijos išvestis
Priėmimo taisyklė / rankinis skaičiavimas
priklausomybė
Faktinė DB / tinklas / valanda
Izoliuotas maketu/stubu
krašto dėklas
Tik laimingas kelias
riba, neigiama, klaida
Kai sulaužysite kodą
lieka žalias
pasidaro raudona
Vardas
testas1, testo metodas
aprašo taisyklę, kurią ji patvirtina
Keturi kopijuojami šablonai
1) Taisyklėmis pagrįsto įrenginio testavimas:
Jūsų vaidmuo: vyresnysis programinės įrangos testavimo inžinierius.Parašykite vieneto testą šiai funkcijai naudodami [kalba/framework]: [parašas].Priėmimo taisyklės: [taisyklės].- Naudokite AAA struktūrą.- Rankiniu būdu apskaičiuokite numatomas reikšmes pagal ŠIAS taisykles; NENURODYKITE esamos funkcijos išvesties. - Uždenkite ribą, neigiamą, klaidą ir laimingą kelią atskirais testais. – Tegul kiekvienas testo pavadinimas apibūdina taisyklę, kurią jis patikrina. - Apsimetinėti išorinėmis priklausomybėmis; Kad reali logika veiktų.
2) Mutacijų atsparumo valdymas:
Patikrinkite šiuos vienetų testus. Išvardykite 5 nedidelius testuojamo kodo pakeitimus (a - vietoj +, a >= vietoj >, ribos poslinkis) ir nurodykite kiekvienam iš jų, KURIS iš šių testų taps raudonas? Jei nė vienas negrąžinamas, testas yra nepakankamas.Kodas + testai: [įklijuoti]
3) Bandomumo peržiūra:
Kodėl sunku parašyti šios funkcijos vieneto testą? Paslėpta priklausomybė, pasaulinė padėtis, šalutinis poveikis, ar daug pareigų? Pasiūlykite minimalų pertvarkymą, kad būtų galima išbandyti; nekeisk elgesio. Kodas: [įklijuoti]
4) Neužbaigtas scenarijaus užbaigimas:
Pateikiamos šios funkcijos ir galimi testai. Išvardykite, kuris elgesys / kraštovaizdis NIEKADA nebuvo išbandytas (apimties tarpas) ir kiekvienam pridėkite testą. Funkcija + testai: [įklijuoti]
trys mini dėklai
1 atvejis – kodo atspindėjimo bandymas. Kūrėjas turėjo AI parašyti apvalinimo funkcijos testą; 10 testų buvo žali. Tiesą sakant, funkcija buvo apvalinama neteisinga kryptimi, tačiau AI paėmė laukiamas reikšmes iš funkcijos išvesties, todėl bandymai klaidą laikė „tiesa“. Kai tikėtinos vertės buvo apskaičiuojamos rankiniu būdu naudojant „taisyklėmis pagrįstą“ šabloną, 4 testai tapo raudoni ir paaiškėjo tikroji klaida.
2 atvejis – mutacijų kontrolės reikšmė. Viena komanda pasitikėjo 45 vienetų bandymais. Išbandė 20 nedidelių kodo pakeitimų su „mutacijos tvirtumo patikra“; bandymai jų užfiksavo tik 11. Likę 9 sutrikimai praėjo tyliai. Komanda sustiprino silpnus testus; Atlikus šiuos patobulintus bandymus kitoje laidoje buvo užfiksuota tikroji skaičiavimo klaida.
3 atvejis – netikrumas yra dizaino kvapas. AI negalėjo parašyti užsakymo funkcijos testų, jai nuolat reikėjo tikros duomenų bazės. „Tibamumo peržiūros“ šablonas parodė, kad funkcija įterpta prieigą prie duomenų bazės. Pašalinus priklausomybės injekciją, buvo galima rašyti testus ir kodas tapo švaresnis.
Dažnos klaidos
- Tikėtinos vertės išvedimas iš kodo. AI priima funkcijos išvestį kaip „teisingą“; testas, patvirtinantis klaidingą kodą.
- Bandymas be teiginio arba su trivialiu teiginiu. „Jis neišmetė klaidos, praėjo“ logika; Tai nieko nepatvirtina.
- Ekstremalus pasityčiojimas. Iš visko tyčiojantis ir tikrinant tik tai, ką pašaipas grąžina; tikroji logika netikrinama.
- Tiesiog laimingas kelias. Ribinių, neigiamų ir klaidų būsenų apėjimas.
- Netestuojama sulaužant kodą. Pasitikėjimas žalia netikrindamas, ar nėra mutacijų.
- Nepaisoma netikrumo. Neatpažinti ir netaisyti blogo dizaino, užuot verčiau griežtai išbandyti.
Apibendrinant
Vienetiniai testai yra greičiausias ir didžiausias testavimo piramidės sluoksnis; Pagauna klaidą pigiausiu momentu. Dirbtinis intelektas yra labai pajėgus atlikti vienetų testus, tačiau didžiausia jo spąsta yra parašyti testus, kuriuose neteisinga elgsena laikoma „teisinga“, išvedant laukiamą vertę iš paties kodo. Sprendimas: pateikite priėmimo taisykles, apskaičiuokite laukiamas reikšmes rankiniu būdu, vykdykite AAA ir FIRST principus, tyčiokitės iš išorinio pasaulio ir paleiskite tikrąją logiką bei patikrinkite kiekvieną testą mutacija (sulaužydami kodą). Kodas, kurį sunku išbandyti, yra dizaino ženklas, kurį reikia pataisyti.
Taikymo užduotis
Pasirinkite funkciją, kurioje yra verslo taisyklė iš jūsų projekto. Parašykite priėmimo taisykles ir turėkite AI rašymo testus naudodami šabloną „taisyklėmis pagrįsto vieneto testavimas“; Numatytas vertes apskaičiuokite rankiniu būdu. Tada taikykite „mutacijos tvirtumo patikrinimą“: padarykite bent 5 mažas kode pertraukas ir išmatuokite, kiek testų nusidažo raudonai. Pridėkite naują nepagautų korupcijų testą. Praneškite, kiek sutrikimų buvo užfiksuota (pvz., mutacijų balas).
kontrolinis sąrašas
- [ ] Pateikiau priėmimo taisykles ir turėjau rankiniu būdu apskaičiuoti numatomas vertes.
- [ ] Įsitikinau, kad bandymai iš kodo negavo laukiamos vertės.
- [ ] Sukūriau nepriklausomą testavimą vadovaudamasis AAA ir FIRST gairėmis.
- [ ] Aš pasityčiojau iš išorinių priklausomybių ir paleidau tikrąją logiką.
- [ ] Aptariau ribinius, neigiamus ir klaidų atvejus.
- [ ] Sulaužydamas kodą (mutaciją) įrodžiau, kad testai tikrai apsaugo.