zisky:
- Schopnost vytvářet testování jednotek, okrajové případy a analýzu mezer pokrytí pomocí AI
- Možnost vytisknout očekávání testu na základě specifikace, nikoli aktuálního chování kódu
- Schopnost otestovat, zda test skutečně chrání vložením chyb
Psaní testů je jedním z nejhodnotnějších úkolů, které většina vývojářů odkládá. Dobrá testovací sada je důkazem, že kód funguje podle očekávání, a záchranným lanem pro budoucí změny. Problém je v tom, že psaní testů je opakované a časově náročné – přesně ten druh práce, kde AI září. Má to ale háček: AI často testuje stávající chování kódu, nikoli chování, které by mělo být. Správa tohoto rozdílu je podstatou této jednotky.
V této lekci se naučíte testování jednotek (testování, které testuje funkci samostatně, izolovaně), testy hraničních případů a generování testovacích dat pomocí AI; zacelení mezer v pokrytí testem; a proč je slepé důvěřovat testům AI nebezpečné.
Dvě strany testování: Oprava chování vs. ověření
Test může sloužit dvěma různým účelům. První je ověření: testuje, zda je kód správný, zda odpovídá specifikaci. Druhým je regresní ochrana: zmrazí chování kódu dnes, takže pokud jej někdo zítra náhodou změní, test se přeruší a upozorní.
AI je v tom druhém velmi dobrá; Podívá se na kód a generuje případy, které testují, „co právě dělá“. Ale pokud je kód od začátku špatný, umělá inteligence může toto špatné chování označit jako „správné“. Takže musíte zkontrolovat tvrzení každého testu, který AI produkuje: „Kód vrací 42 a test očekává 42“ neznamená, že 42 je správná odpověď.
Upozornění: Pokud AI projde testem, neznamená to, že kód „funguje“; znamená to jen „chová se tak, jak AI očekává“. O tom, zda je očekávání správné či nikoli, rozhodnete podle specifikace.
Krok za krokem: Psaní robustních testů s umělou inteligencí
- Uveďte specifikaci, nejen kód. Pokud přidáte informaci „Tato funkce by to měla udělat“, AI může napsat správné očekávání; Pokud zadáte pouze kód, otestuje aktuální chování.
- Požádejte o okrajová pouzdra. Prázdné, nulové, nulové, záporné, příliš velké, špatný formát, souběžnost – explicitně si nárokujte na šťastnou cestu.
- Určete testovací rámec a styl. "použít pytest", "uspořádat-jednat-prosadit vzor", "nechat každý test otestovat jednu věc" atd.
- Zkontrolujte očekávání (tvrzení). Porovnejte se specifikací, kterou každé tvrzení kontroluje správnou hodnotu.
- Zacelit mezery v rozsahu. Proveďte existující testy a zeptejte se "které větve a případy nebyly testovány?" přinutit se zeptat; poté ověřte provedené dodatečné testy.
Tři mini pouzdra
Případ 1 — Pokrytí od 52 % do 85 %. Testovací pokrytí jednoho servisního modulu bylo 52 %. Tým poskytl AI existující testy, nechal ji vypsat netestované větve a vygenerovat pro ně testy. Při kontrole člověkem se pokrytí zvýšilo na 85 %; V tomto procesu AI odhalila skutečnou chybu (cestu, která vrátila nesprávný kód chyby) ve větvi chyby, která nebyla nikdy předtím testována.
Případ 2 – Past fixace falešného očekávání. Funkce zaokrouhlování peněz byla ve skutečnosti špatná; Místo zaokrouhlení 2,675 na 2,67 bylo zaokrouhleno 2,67 místo 2,68. Umělá inteligence se podívala na kód a napsala claim round_money(2,675) == 2,67 — zmrazení chyby jako „pravda“. Když si vývojář přečetl specifikaci, opravil očekávání a zachytil skutečnou chybu. Testování pravidla, nikoli kódu, přineslo rozdíl.
Případ 3 – Exploze v okrajovém stavu. Když žádáte AI pouze o „okrajové případy“ pro funkci období; Vytvořilo 8 případů, jako je začátek=konec, reverzní interval, přestupný rok 29. února, různá časová pásma a nulový interval. Dva z nich (obrácené mezery a přestupný rok) ve skutečnosti způsobily chybu. Ruční zvažování těchto případů se často přeskakuje; Umělá inteligence se zde stala partnerem pro „edge-case brainstorming“.
Čtyři kopírovatelné šablony
Generování testu na základě specifikace:
Role: Vývojář, který píše testy. Rámec: {{pytest/JUnit/Jest...}}. Co by funkce MĚLA UDĚLAT (specifikace): {{rule}}Napište testy pro následující funkci. Napište očekávání podle specifikace, NE aktuálního výstupu kódu. Šťastná cesta + přidejte alespoň 4 okrajové případy. Nechte každý test otestovat jednu věc, použijte popisný název. {{funkce}}
Brainstorming Edge case:
Vyjmenujte případy hran/selhání, které by se měly vyzkoušet při testování této funkce (null, null, body přerušení, špatný formát, souběžnost, externí chyba). Pro každý případ: vstup, očekávané chování. Kód zatím NEPIŠTE, pouze jej uveďte.{{funkce}}
Analýza mezery v pokrytí:
Níže jsou uvedeny funkce a dostupné testy. Které větve, podmínky a případy nebyly testovány? Vyjmenujte nedostatky a nové testy pište pouze na nedostatky. Neopakujte stávající. Funkce:{{function}}Testy:{{existující_testy}}
Testovací data / generování simulovaného objektu:
Vytvářejte realistická testovací data pro testy {{funkce/služby}}: platné vzorky, hraniční vzorky a neplatné vzorky samostatně. Navrhněte jednoduché simulované chování pro externí závislost {{X}}. Používání skutečných důvěrných údajů/PII; Vytvářejte falešná data.
Slabá výzva / Silná výzva
Slabé: "Napište test pro tuto funkci."
Silné: "s pytestem. Funkce apply_discount(total, procento) — pravidlo: sleva musí být 0%–30%, mimo meze by měla vyvolat ValueError, výsledek by měl být zaokrouhlen na 2 desetinná místa. Napište očekávání podle tohoto PRAVIDLA (nikoli pomocí kódu). Šťastná cesta + tyto okrajové případy: 0%, 30%, 31% (chyba), záporné, celkem=0"
Dává pravidlo silného uvolnění a říká „pište očekávání podle pravidla, ne podle kódu“; Tato jediná věta uzavírá past AI, která opravuje špatné chování.
Typ testu
Příspěvek AI
lidská kontrola
Hodně štěstí při testování silničních jednotek
rychlá kostra
Je očekávání správné?
Okrajové případy
Rozsáhlý brainstorming
Odstraňte nepodstatné
Vyplnění mezery rozsahu
Najde přeskočené větve
Potvrďte význam
Testovací data/falešná
Vytváří realistický vzorek
Žádné PII, kontrola realismu
Testy řídí kvalitu, nezaručují ji
Vysoké pokrytí testem dává jistotu, ale může být také zavádějící: 100procentní pokrytí znamená „každá řádka byla spuštěna“, nikoli „každá řádka je správná“. Je snadné zvýšit pokrytí pomocí AI; Skutečná hodnota je v psaní smysluplných očekávání. Hodnota testu je jeho schopnost prolomit a upozornit vás na porušení kódu. Proto jsou testy generované umělou inteligencí založeny na otázce „skutečně se kód rozbije, když se změní?“. Otestujte to otázkou; Záměrné přerušení čáry a vidění přerušení testu (myšlenka mutace) je důkazem, že test fungoval.
Tip: Chcete-li zjistit, zda test zapsaný AI funguje, vytvořte v kódu malou chybu (např. změňte + na a -) a zjistěte, zda test nefunguje. Pokud se nerozbije, tento test vás nechrání.
Časté chyby
- Žádost o test bez uvedení pravidla. Model zmrazí aktuální chování; opraví chybu jako "pravda".
- Přijetí očekávání, aniž byste je četli. Testování je zavádějící, pokud nezkontrolujete, že aserce kontrolují správnou hodnotu.
- Jen otestovat šťastnou cestu. Skutečné chyby žijí na okraji; Požádejte výslovně o okrajové případy.
- Záměna rozsahu s účelem. Vysoké procento není zárukou správného chování.
- Vytváření skutečných/skrytých dat jako testovacích dat. Zákaznická data nebo tajemství by neměla vstupovat do testování a ukládání; Generování syntetických dat.
V souhrnu
Umělá inteligence odstraňuje velkou část opakované zátěže při psaní testů: vytváří rychlé kostry, velké seznamy okrajových případů a analýzy mezer v pokrytí. Ale nejkritičtějším bodem jsou očekávání: AI má tendenci testovat aktuální chování kódu, zatímco testování by mělo být psáno podle specifikace. Dejte pravidlo, zkontrolujte očekávání, vynucujte okrajové případy a otestujte, zda testy skutečně chrání zavedením chyby. Testovací pokrytí je nástroj, nikoli cíl.
Aplikační úkol
Vyberte funkci a nejprve vytiskněte test pro AI jednoduchým zadáním kódu; Všimněte si očekávání. Poté znovu vytiskněte test s uvedením specifikace (požadovaného chování) pro stejnou funkci. Porovnejte očekávání dvou testovacích sad: Liší se nějak, která z nich odhaluje skutečnou chybu? Nakonec ověřte, že jeden z vygenerovaných testů fungoval, přidáním záměrné chyby do kódu a zobrazením přerušení testu.
kontrolní seznam
- [ ] Rozlišuji, zda má test chování opravit nebo ověřit.
- [ ] Když žádám o test, dávám pravidlo (specifikaci), které by mělo být na místě, ne kód.
- [ ] Porovnávám každé vygenerované tvrzení se specifikací.
- [ ] Výslovně požaduji případy hran a selhání.
- [ ] Procentuální pokrytí vnímám jako nástroj, nikoli cíl.
- [ ] Testuji, zda test skutečně chrání vložením chyb.