Ieguvumi:
- Spēja neļaut mākslīgajam intelektam pieņemt kļūdainu uzvedību kā “pareizu”, aprēķinot paredzamo vērtību vienību testos neatkarīgi no pieņemšanas noteikuma
- Spēja drukāt ātrus, neatkarīgus un atkārtojamus testus, piemērojot AAA un FIRST principus un izsmejot ārējās atkarības
- Spēja pārbaudīt testus ar mutāciju (koda laušanu) un atpazīt grūti pārbaudāmu kodu kā dizaina smaku
Lielākais un ātrākais testēšanas piramīdas slānis ir vienību testēšana — testēšana, kas pārbauda funkciju vai nelielu koda daļu atsevišķi no visa pārējā. Tūkstošiem vienību testu tiek izpildīti dažu sekunžu laikā un konstatē kļūdu, kamēr kods joprojām atrodas izstrādātāja ekrānā. Mākslīgais intelekts (AI), iespējams, ir visprasmīgākais vienību testu izveidē: jūs piešķirat tam funkciju, AI ražo desmitiem testu. Taču šīs ērtības rada vislielāko slazdu: AI viegli izveido testus, kas “spīd zaļā krāsā, bet neko nepārbauda” vai pieņem pašreizējo (iespējams, kļūdaino) koda darbību kā “pareizu”. Šajā nodaļā jūs uzzināsit, kā rakstīt patiesi aizsargājošus vienību testus ar AI un saikni starp pārbaudāmo kodu un AI.
Labas vienības pārbaudes īpašības: PIRMĀ
Labi vienību testi atbilst FIRST principiem: ātrs, neatkarīgs (testiem nevajadzētu būt vienam no otra atkarīgiem), atkārtojams (atkārtojams — vienāds rezultāts jebkurā vidē), pašpārbaudes (tīri nokārtots/nesekmīgs), savlaicīgs (laikā). Atgādiniet sev šos principus, kad mākslīgais intelekts veido testus; īpaši lūgt, lai tests nebūtu atkarīgs no ārpasaules (faktiskās datu bāzes, tīkla, pulksteņa), lai tas būtu "neatkarīgs" un "atkārtojams".
AAA raksts un izteiksmīgs apgalvojums
Cietās vienības tests atbilst AAA struktūrai: Sakārtot (sagatavot — iestatiet ievades un atkarības), Rīkojieties (izpildiet — izsauciet pārbaudāmo funkciju), Apstiprināt (apstiprināt — salīdziniet rezultātu ar paredzamo vērtību). Kritiskais ir apgalvojums. Visizplatītākā kļūda, ko pieļauj AI, ir apgalvojuma atvasināšana no pārbaudāmā koda izvades — loģika “viss, ko kods atgriež, ir patiess”. Tas padara testu bezjēdzīgu. Pareizais veids ir neatkarīgi noteikt paredzamo vērtību (no pieņemšanas kritērijiem aprēķiniet to manuāli).
Uzmanību: ja jūs sakāt AI “uzrakstīt šīs funkcijas pārbaudi”, AI var palaist funkciju un rakstīt tās izvadi kā “paredzēto”. Šis tests iztur pat tad, ja funkcija ir nepatiesa. Tā vietā sakiet: "Jūs aprēķinājat sagaidāmos rezultātus saskaņā ar šiem noteikumiem, neatsaucieties uz funkcijas pašreizējo izvadi."
Izsmiekli, stukači un atkarības
Vienības pārbaudei nepieciešama izolācija. Ja jūsu funkcija ir atkarīga no datu bāzes vai API, testēšanas laikā tie tiek aizstāti ar imitētiem objektiem (mock/stub — kontrolēts, fiktīvs reālās atkarības aizstājējs). Tas padara testu ātru, neatkarīgu un reproducējamu. AI var radīt viltotu instalāciju; Taču uzmanieties no pārmērīgas ņirgāšanās: ja jūs visu izsmejat, tests pārbaudīs tikai to, "ko izspēle atgriež", nevis faktisko loģiku. Līdzsvars: atdariniet ārpasauli, izpildiet pārbaudāmo reālo loģiku.
Pārbaudāmība un AI
Ir interesantas atsauksmes: kods, kuru ir grūti pārbaudīt, bieži ir slikti izstrādāts kods. Ja mākslīgajam intelektam ir problēmas ar funkcijas testu rakstīšanu (pārāk daudz atkarību, slēpts globālais stāvoklis, blakusparādības), tā ir dizaina smarža. Jautājot AI “kā jūs pārveidotu šo kodu, lai tas būtu pārbaudāms”, tiek nodrošināta gan labāka pārbaude, gan labāks kods.
Parametru testi un datu daudzveidība
Atsevišķa testa rakstīšana katru reizi, lai pārbaudītu vienu un to pašu noteikumu ar dažādiem ievades datiem, ir nogurdinoši un grūti uzturējami. Parametrizētā testēšana — struktūra, kas atkārtoti palaiž vienu un to pašu testa loģiku ievades datu un sagaidāmo rezultātu sarakstā — novērš šo atkārtošanos: viens testa korpuss tiek barots ar desmitiem ievades pāru. AI ļoti efektīvi veido šīs ievades sagaidāmo rezultātu tabulas, ja piešķirat tam savus pieņemšanas noteikumus; Jo īpaši tajā sistemātiski tiek apkopotas robežvērtības un ekvivalences klases.
Bet arī šeit ir slazds: AI mēdz iegūt gaidītos rezultātus ģenerētajā tabulā no testējamā koda. Šī kļūda ir vēl bīstamāka parametrizētajā testēšanā, jo viena nepareiza loģika padara nederīgus desmitiem rindu. Tāpēc vienmēr ļaujiet paredzamā rezultāta kolonnai aprēķināt neatkarīgi saskaņā ar pieņemšanas noteikumu un manuāli apstiprināt vismaz dažas rindas. Pieprasiet arī apraksta kolonnu "ko katra rinda pārstāv"; tāpēc, kad rinda pārtrauc, jūs uzreiz redzat, kurš stāvoklis ir bojāts.
Padoms. Parametrizētajai testa tabulai ar nolūku pievienojiet “slazdu rindu” — tas ir, apzināti nepareizi ierakstiet rezultātu. Ja šī līnija nekļūst sarkana, palaižot testu, jūsu tests faktiski nepārbauda šo situāciju. Šī ir ātra izspēles pārbaude.
Vāja uzvedne / spēcīga uzvedne
Vāji: "Uzrakstiet šīs funkcijas vienības testu."
Strong: rakstiet [valodas/ietvara] vienību testus funkcijai "taxCalculate(summa, rate). Pieņemšanas noteikums: rezultāts = summa * likme, noapaļota līdz 2 decimālzīmēm; negatīva summa vai likme rada kļūdu; atgriež 0, ja likme ir 0. Izmantojiet AAA struktūru. Manuāli aprēķiniet sagaidāmās vērtības saskaņā ar ŠEJIEM likumiem. Manuāli aprēķiniet sagaidāmās vērtības saskaņā ar ŠIEM likumiem; neatsaucieties uz negatīviem gadījumiem Co, 0. Lai katra testa nosaukums apraksta kārtulu, ko tas pārbauda.
Spēcīga uzvedne; Tas sniedz pieņemšanas noteikumu, neatkarīgas paredzamās vērtības sagaidāmās vērtības, struktūru un malas gadījumus. Tādējādi tests kļūst par noteikumu sargu, nevis koda spoguli.
Vienības pārbaudes kvalitātes tabula
simptoms
Slikts tests (viltus uzticēšanās)
labs tests
apgalvot
Nav vai "nav null"
Paredzamā konkrētā vērtība
Paredzamais vērtības avots
Funkcijas izvade
Pieņemšanas noteikums / manuāls aprēķins
atkarība
Faktiskais DB/tīkls/stunda
Siltināts ar mock/stub
malas korpuss
Tikai laimīgs ceļš
limits, negatīvs, kļūda
Kad jūs pārkāpjat kodu
paliek zaļš
kļūst sarkans
Vārds
test1, testa metode
apraksta noteikumu, ko tas apstiprina
Četras kopējamas veidnes
1) Noteikumu vadītu vienību testēšana:
Jūsu loma: vecākais programmatūras testēšanas inženieris.Uzrakstiet vienības testu par šādu funkciju ar [valoda/ietvars]: [paraksts].Pieņemšanas noteikumi: [noteikumi].- Izmantojiet AAA struktūru.- Manuāli aprēķiniet paredzamās vērtības saskaņā ar ŠIEM noteikumiem; NEATSAUC uz funkcijas pašreizējo izvadi. - Nosedziet ierobežojumu, negatīvo, kļūdu un laimīgo ceļu ar atsevišķiem testiem. - Katrs testa nosaukums apraksta noteikumu, ko tas pārbauda. - Izspēles ārējās atkarības; Lieciet faktiskajai loģikai darboties.
2) Mutācijas pretestības kontrole:
Pārbaudiet šos vienību testus. Uzskaitiet 5 nelielus pielāgojumus, ko es varētu veikt pārbaudāmajā kodā (a + vietā, a >= > vietā, robežu nobīde) un katram no tiem pastāstiet, KURŠ no šiem testiem kļūs sarkans? Ja neviens netiek atgriezts, tests ir nepietiekams.Kods + testi: [ielīmēt]
3) Pārbaudāmības pārskats:
Kāpēc ir grūti uzrakstīt vienības testu šai funkcijai? Slēptā atkarība, globālais statuss, blakusefekti, vai ir daudz pienākumu? Ieteikt minimālu pārstrukturēšanu, lai padarītu to pārbaudāmu; nemaina uzvedību. Kods: [ielīmēt]
4) Nepilnīga scenārija pabeigšana:
Ir dotas šādas funkcijas un pieejamie testi. Uzskaitiet, kura darbība/malas gadījums NEKAD nav pārbaudīts (tvēruma atstarpe), un katram pievienojiet testu. Funkcija + testi: [ielīmēt]
trīs mini futrāļi
1. gadījums — koda atspoguļošanas pārbaude. Izstrādātājs lika AI uzrakstīt noapaļošanas funkcijas testu; 10 testi bija zaļi. Faktiski funkcija tika noapaļota nepareizā virzienā, bet AI no funkcijas izvades bija paņēmis sagaidāmās vērtības, tāpēc pārbaudēs kļūda tika uzskatīta par "patiesu". Kad paredzamās vērtības tika manuāli aprēķinātas, izmantojot "noteikumu vadīto" veidni, 4 testi kļuva sarkani un tika atklāta patiesā kļūda.
2. gadījums — mutāciju kontroles vērtība. Viena komanda paļāvās uz 45 vienību testiem. Izmēģināja 20 nelielus koda pielāgojumus ar "mutācijas noturības pārbaudi"; pārbaudēs tika noķerti tikai 11 no tiem. Atlikušie 9 traucējumi pagāja klusi. Komanda pastiprināja vājās pārbaudes; Šajos uzlabotajos testos nākamajā laidienā tika konstatēta faktiska aprēķina kļūda.
3. gadījums — nepārbaudāmība ir dizaina smarža. AI nevarēja uzrakstīt testus pasūtīšanas funkcijai, tai pastāvīgi bija nepieciešama reāla datu bāze. "Pārbaudāmības pārskata" veidne parādīja, ka funkcija iegulta piekļuvi datu bāzei. Kad atkarības injekcija tika noņemta, varēja rakstīt testus un kods kļuva tīrāks.
Biežas kļūdas
- Paredzamās vērtības atvasināšana no koda. AI pieņem funkcijas izvadi kā "pareizu"; tests, kas apstiprina kļūdainu kodu.
- Pārbaude bez apgalvojuma vai ar triviālu apgalvojumu. "Viņš neiemeta kļūdu, viņš nokārtoja" loģika; Tas neko neapstiprina.
- Ekstrēms izspēles. Izsmejot visu un pārbaudot tikai to, ko izspēles atdod; reālā loģika netiek pārbaudīta.
- Tikai laimīgais ceļš. Robežas, negatīvo un kļūdu stāvokļu apiešana.
- Nepārbauda, pārtraucot kodu. Uzticoties zaļajam, nepārbaudot mutāciju.
- Nepārbaudāmības ignorēšana. Sliktā dizaina neatpazīšana un labošana, nevis stingras pārbaudes.
Rezumējot
Vienības testi ir ātrākais un lielākais testēšanas piramīdas slānis; Tā pieķer kļūdu lētākajā brīdī. AI ir ļoti spējīgs izveidot vienību testus, taču tā lielākā kļūme ir tādu testu rakstīšana, kuros nepareiza darbība tiek uzskatīta par "pareizu", paredzamo vērtību atvasinot no paša koda. Risinājums: sniedziet pieņemšanas noteikumus, manuāli aprēķiniet sagaidāmās vērtības, ieviesiet AAA un FIRST principus, izsmiet ārpasauli un palaidiet faktisko loģiku un pārbaudiet katru testu ar mutāciju (koda laušanu). Kods, kuru ir grūti pārbaudīt, ir dizaina zīme, kas ir jālabo.
Lietojumprogrammas uzdevums
Atlasiet funkciju, kas satur biznesa noteikumu no sava projekta. Uzrakstiet pieņemšanas noteikumus un AI rakstiet testus, izmantojot veidni “noteikumu vadīta vienību pārbaude”; Aprēķiniet paredzamās vērtības manuāli. Pēc tam veiciet “mutācijas robustuma pārbaudi”: kodā veiciet vismaz 5 nelielus pārtraukumus un izmēriet, cik testu kļūst sarkani. Pievienojiet jaunu testu nenotvertiem bojājumiem. Ziņojiet, cik daudz traucējumu tika konstatēti (piemēram, mutācijas rezultāts).
kontrolsaraksts
- [ ] Es norādīju pieņemšanas noteikumus un liku manuāli aprēķināt paredzamās vērtības.
- [ ] Es pārliecinājos, ka testos nav iegūta paredzamā vērtība no koda.
- [ ] Esmu izveidojis neatkarīgu testēšanu, ievērojot AAA un FIRST vadlīnijas.
- [ ] Es izsmēju ārējās atkarības un izmantoju faktisko loģiku.
- [ ] Es aplūkoju limita, negatīvo un kļūdu gadījumus.
- [ ] Pārkāpjot kodu (mutāciju), es pierādīju, ka testi patiešām aizsargā.