Kasu:
- Võimalus takistada tehisintellektil ekslikku käitumist "õigeks" aktsepteerimast, arvutades ühikutestides eeldatava väärtuse sõltumata aktsepteerimisreeglist
- Võimalus printida kiireid, sõltumatuid ja korratavaid teste, rakendades AAA ja FIRST põhimõtteid ning pilkades väliseid sõltuvusi
- Oskus testida teste mutatsiooniga (koodimurdmisega) ja tunda ära raskesti testitavat koodi disainilõhnana
Testimispüramiidi suurim ja kiireim kiht on ühiktestimine – testimine, mis kontrollib funktsiooni või väikest koodijuppi kõigest muust eraldatuna. Tuhanded seadmetestid käivituvad sekunditega ja tuvastavad vea, kui kood on veel arendaja ekraanil. Tehisintellekt (AI) on võib-olla kõige osavam ühikutestide tegemisel: teie annate sellele funktsiooni, tehisintellekt toodab kümneid teste. Kuid just see mugavus tekitab suurima lõksu: AI loob hõlpsalt teste, mis "helendavad roheliselt, kuid ei kontrolli midagi" või aktsepteerivad koodi praegust (võib-olla vigast) käitumist kui "õiget". Selles üksuses saate teada, kuidas kirjutada tehisintellektiga tõeliselt kaitsvaid seadmeteste ning testitava koodi ja tehisintellekti vahelist seost.
Hea ühikutesti omadused: ESIMESE
Head ühikutestid järgivad FIRST põhimõtteid: kiire, sõltumatu (testid ei tohiks olla üksteisest sõltuvad), korratav (korduv – igas keskkonnas sama tulemus), enesekinnitus (selge läbimine/ebaõnnestumine), õigeaegne (õigeaegselt). Kui lasete tehisintellekti teste koostada, tuletage endale neid põhimõtteid meelde; konkreetselt paluge, et test ei sõltuks välismaailmast (tegelik andmebaas, võrk, kell), et see oleks "sõltumatu" ja "korratav".
AAA muster ja väljendusrikas kinnitus
Tahke ühiku test järgib AAA struktuuri: Korralda (valmistage - seadistage sisendid ja sõltuvused), Tegutse (käivita - kutsuge testitav funktsioon), Kinnitage (kinnitage - võrrelge tulemust eeldatava väärtusega). Kriitiline on kinnitamine. Kõige tavalisem viga, mida AI teeb, on väite tuletamine testitava koodi väljundist - loogika "mis iganes kood tagastab, on tõene". See muudab testi mõttetuks. Õige viis on eeldatava väärtuse määramine iseseisvalt (vastuvõtukriteeriumide põhjal arvutage see käsitsi).
Tähelepanu: kui ütlete AI-le "kirjutage selle funktsiooni jaoks test", võib AI funktsiooni käivitada ja kirjutada selle väljundi oodatuks. See test läbib isegi siis, kui funktsioon on väär. Selle asemel öelge: "Arvutate eeldatavad tulemused nende reeglite järgi, ärge viidake funktsiooni praegusele väljundile."
Pilkad, tõmblused ja sõltuvused
Üksuse testimine nõuab isoleerimist. Kui teie funktsioon sõltub andmebaasist või API-st, asendatakse need testimisel näidisobjektidega (mock/stub – tegeliku sõltuvuse kontrollitud näiv asendaja). See muudab testi kiireks, sõltumatuks ja reprodutseeritavaks. AI võib luua näidisinstallatsiooni; Kuid hoiduge liigsest mõnitamisest: kui mõnitate kõike, kontrollib test ainult seda, "mida mõnitamine tagastab", mitte tegelikku loogikat. Tasakaal: jäljendage välismaailma, rakendage testitavat tegelikku loogikat.
Testitavus ja AI
Seal on huvitav tagasiside: kood, mida on raske testida, on sageli halvasti kujundatud kood. Kui AI-l on probleeme funktsiooni testide kirjutamisega (liiga palju sõltuvusi, varjatud globaalne olek, kõrvalmõjud), on see disaini lõhn. Tehisintellekti küsimine "kuidas te selle koodi ümber kujundaksite, et see testitavaks muuta" toob kaasa nii parema testimise kui ka parema koodi.
Parameetrilised testid ja andmete mitmekesisus
Iga kord eraldi testi kirjutamine sama reegli kontrollimiseks erinevate sisenditega on nii tüütu kui ka raskesti hooldatav. Parameetriline testimine – struktuur, mis kasutab korduvalt sama testimisloogikat sisendite ja oodatavate tulemuste loendis – välistab selle kordamise: ühte testimiskeha toidetakse kümnete sisendpaaridega. Tehisintellekt on nende sisendiga eeldatavate tulemuste tabelite loomisel väga tõhus, kui annate sellele oma aktsepteerimisreeglid; Eelkõige tabeldab see süstemaatiliselt piirväärtusi ja samaväärsuse klasse.
Kuid ka siin on lõks: AI kipub testitava koodi põhjal genereeritud tabelis oodatud tulemusi tuletama. See viga on parameetritega testimisel veelgi ohtlikum, sest üksainus vale loogika muudab kümned read kehtetuks. Seetõttu laske oodatava tulemuse veerg alati iseseisvalt vastavalt aktsepteerimisreeglile arvutada ja kinnitage käsitsi vähemalt paar rida. Küsi ka kirjelduse veergu "mida iga rida tähistab"; nii et kui rida katkeb, näete koheselt, milline olek on katki.
Näpunäide. Lisage parameetritega testimise tabelisse tahtlikult "lõksurida" – see tähendab, et sisestage tulemus teadlikult valesti. Kui see rida ei muutu testi käivitamisel punaseks, ei kinnita test tegelikult seda olukorda. See on kiire näidisläbimise kontroll.
Nõrk viip / Tugev viip
Nõrk: "Kirjutage selle funktsiooni jaoks ühikutest."
Tugev: kirjutage funktsiooni "taxCalculate(summa, määr) jaoks [keele/raamistiku] ühikutestid. Aktsepteerimisreegel: tulemus = summa * määr, ümardatud 2 kümnendkohani; negatiivne summa või määr annab vea; tagastab 0, kui määr on 0. Kasutage AAA-struktuuri. Arvutage käsitsi eeldatavad väärtused vastavalt NENDE reeglitele; ärge viidake funktsiooni praegusele negatiivsele väljundile (ver, 0 ja negatiivsed juhud. kümnendkohtadeni). Kirjeldagu iga testi nimi reeglit, mida see kontrollib.
Võimas viip; See annab aktsepteerimisreegli, sõltumatu oodatava väärtuse ootuse, struktuuri ja servajuhtumid. Seega saab testist reegli valvur, mitte koodi peegel.
Ühikutesti kvaliteeditabel
sümptom
Halb test (võltsusaldus)
hea test
väita
Puudub või "pole null"
Eeldatav betooni väärtus
Eeldatav väärtuse allikas
Funktsiooni väljund
Vastuvõtmise reegel / käsitsi arvutamine
sõltuvus
Tegelik DB/võrk/tund
Isoleeritud mock/stubiga
serva korpus
Ainult õnnelik tee
piir, negatiivne, viga
Kui rikute koodi
jääb roheliseks
muutub punaseks
Nimi
test1, katsemeetod
kirjeldab reeglit, mida see kinnitab
Neli kopeeritavat malli
1) Reeglipõhise üksuse testimine:
Teie roll: vanemtarkvara testimise insener.Kirjutage ühikutest järgmise funktsiooniga [keel/raamistik]: [allkiri]. Nõustureeglid: [reeglid].- Kasutage AAA struktuuri.- Arvutage eeldatavad väärtused käsitsi vastavalt NENDE reeglitele; ÄRGE viidake funktsiooni praegusele väljundile. - Katke piir, negatiivne, viga ja õnnelik tee eraldi testidega. - Laske iga testi nimi kirjeldada reeglit, mida see kontrollib. - pilka väliseid sõltuvusi; Pange tegelik loogika tööle.
2) Mutatsioonikindluse juhtimine:
Vaadake neid ühikuteste. Loetlege 5 väiksemat muudatust, mida saaksin testitavas koodis teha (a - + asemel, a >= > asemel, piirinihe) ja öelge mulle igaühe puhul, MILLINE neist testidest muutub punaseks? Kui ühtegi ei tagastata, on test ebapiisav. Kood + testid: [kleebi]
3) Testitatavuse ülevaade:
Miks on selle funktsiooni jaoks keeruline ühiktesti kirjutada? Varjatud sõltuvus, globaalne staatus, kõrvalmõjud, kas on palju kohustusi? Soovitage minimaalset refaktoreerimist, et see oleks testitav; ära muuda käitumist. Kood: [kleebi]
4) Mittetäielik stsenaariumi täitmine:
Antakse järgmised funktsioonid ja saadaolevad testid. Loetlege, millist käitumist/servajuhtumit EI ole KUNAGI testitud (ulatuse vahe) ja lisage igaühe jaoks test. Funktsioon + testid: [kleebi]
kolm minikarpi
Juhtum 1 – testi peegeldab koodi. Arendaja lasi AI-l kirjutada ümardamisfunktsiooni testi; 10 testi olid rohelised. Tegelikult ümardas funktsioon vales suunas, kuid AI oli funktsiooni väljundist võtnud oodatud väärtused, nii et testid pidasid viga "tõene". Kui eeldatavad väärtused arvutati käsitsi "reeglipõhise" malliga, muutus 4 testi punaseks ja tegelik viga ilmnes.
Juhtum 2 – mutatsioonikontrolli väärtus. Üks meeskond tugines 45 üksuse testile. Proovisin koodis 20 väiksemat muudatust "mutatsioonikindluse kontrolliga"; katsed tabasid neist vaid 11. Ülejäänud 9 häiret möödusid vaikselt. Meeskond tugevdas nõrku teste; Need täiustatud testid tuvastasid järgmises versioonis tegeliku arvutusvea.
Juhtum 3 – testimatus on disaini lõhn. AI ei saanud tellimisfunktsiooni jaoks teste kirjutada, see vajas pidevalt tõelist andmebaasi. "Testitavuse ülevaate" mall näitas, et funktsioon sisaldab juurdepääsu andmebaasile. Kui sõltuvussüst eemaldati, sai teste kirjutada ja kood sai puhtamaks.
Levinud vead
- Eeldatava väärtuse tuletamine koodist. AI aktsepteerib funktsiooni väljundit kui "õiget"; test, mis kinnitab vigase koodi.
- Test ilma väiteta või triviaalse väitega. "Ta ei visanud viga, läks mööda" loogika; See ei kinnita midagi.
- Äärmuslik pilkamine. Nakata kõike ja katsetada ainult seda, mida pilkamine annab; tegelikku loogikat ei testita.
- Lihtsalt õnnelik tee. Piiri-, negatiivse- ja veaolekute ümbersõit.
- Ei testita koodi murdmisega. Usalda rohelist ilma mutatsiooni kontrollimata.
- Testimatuse ignoreerimine. Raske testimise asemel ei tuvasta ja paranda halba disaini.
Kokkuvõttes
Ühiktestid on testimispüramiidi kiireim ja suurim kiht; See tabab vea kõige odavamal hetkel. AI on väga võimeline tootma ühikuteste, kuid selle suurim lõks on selliste testide kirjutamine, mis eeldavad vale käitumist kui "õiget", tuletades koodist endast eeldatava väärtuse. Lahendus: andke aktsepteerimisreeglid, laske eeldatavad väärtused käsitsi arvutada, jõustage AAA ja FIRST põhimõtted, pilkake välismaailma ja käivitage tegelik loogika ning testige iga testi mutatsiooniga (koodi murdmisega). Raskesti testitav kood on kujundusmärk, mis vajab parandamist.
Rakenduse ülesanne
Valige funktsioon, mis sisaldab teie enda projektist ärireeglit. Kirjutage vastuvõtmise reeglid ja laske tehisintellektil kirjutada teste malliga „reeglipõhise üksuse testimine”; Laske eeldatavad väärtused käsitsi arvutada. Seejärel rakendage "mutatsioonikindluse kontrolli": tehke koodis vähemalt 5 väikest pausi ja mõõtke, mitu testi muutub punaseks. Lisage tabamata korruptsioonide jaoks uus test. Teatage, kui palju häireid tuvastati (nt mutatsiooniskoor).
kontrollnimekiri
- [ ] Andsin vastuvõtmise reeglid ja lasin eeldatavad väärtused käsitsi arvutada.
- [ ] Veendusin, et testid ei tuleta koodist oodatud väärtust.
- [ ] Olen loonud sõltumatu testimise, järgides AAA ja FIRST juhiseid.
- [ ] Pilkasin väliseid sõltuvusi ja käivitasin tegeliku loogika.
- [ ] Käsitlesin piir-, negatiivseid ja veajuhtumeid.
- [ ] Koodi murdmisega (mutatsiooniga) tõestasin, et testid tõepoolest kaitsevad.