zisky:
- Schopnost zabránit umělé inteligenci přijmout chybné chování jako „správné“ výpočtem očekávané hodnoty v jednotkových testech nezávisle na pravidle přijetí
- Schopnost tisknout rychlé, nezávislé a opakovatelné testy použitím principů AAA a FIRST a zesměšňováním externích závislostí
- Schopnost testovat testy s mutací (rozbití kódu) a rozpoznat obtížně testovatelný kód jako vůni designu
Největší a nejrychlejší vrstvou testovací pyramidy je testování jednotek – testování, které ověřuje funkci nebo malý kousek kódu izolovaně od všeho ostatního. Tisíce jednotkových testů běží během několika sekund a zachycují chybu, zatímco je kód stále na obrazovce vývojáře. Umělá inteligence (AI) je možná nejzkušenější ve výrobě jednotkových testů: když jí dáte funkci, AI vytvoří desítky testů. Právě tato vymoženost však vede k největší pasti: AI snadno vytváří testy, které „svítí zeleně, ale nic neověřují“ nebo přijímají aktuální (možná chybné) chování kódu jako „správné“. V této lekci se naučíte, jak psát skutečně ochranné testy jednotek s AI a vztah mezi testovatelným kódem a AI.
Vlastnosti dobrého testu jednotek: PRVNÍ
Dobré jednotkové testy se řídí PRVNÍmi zásadami: Rychlé, Nezávislé (testy by na sobě neměly být závislé), Opakovatelné (opakovatelné – stejný výsledek v jakémkoli prostředí), Vlastní validace (vymazat vyhověl/nevyhověl), Včas (včas). Připomeňte si tyto principy, když necháte AI produkovat testy; konkrétně požádejte, aby test nezávisel na vnějším světě (aktuální databáze, síť, hodiny), aby byl „nezávislý“ a „opakovatelný“.
AAA vzor a výrazové prosazení
Test pevných jednotek se řídí strukturou AAA: Uspořádat (připravit – nastavit vstupy a závislosti), Act (provést – zavolat testovanou funkci), Assert (ověřit – porovnat výsledek s očekávanou hodnotou). Kritickým je tvrzení. Nejčastější chybou, kterou AI dělá, je odvození tvrzení z výstupu testovaného kódu – logika „cokoli kód vrátí, je pravda“. Tím test ztrácí smysl. Správným způsobem je stanovit očekávanou hodnotu nezávisle (z akceptačních kritérií ji vypočítat ručně).
Upozornění: Pokud řeknete AI „napiš test pro tuto funkci“, AI může funkci spustit a zapsat její výstup jako „očekávaný“. Tento test projde, i když je funkce nepravdivá. Místo toho řekněte „počítáte očekávané výsledky podle těchto pravidel, neodkazujte na aktuální výstup funkce“.
Zesměšňování, útržky a závislosti
Testování jednotek vyžaduje izolaci. Pokud vaše funkce závisí na databázi nebo API, jsou při testování nahrazeny falešnými objekty (mock/stub – kontrolovaná, falešná náhrada skutečné závislosti). Díky tomu je test rychlý, nezávislý a reprodukovatelný. AI může vytvořit falešnou instalaci; Pozor ale na přehnané zesměšňování: pokud zesměšňujete všechno, test ověří pouze to, „co falešný vrátí“, nikoli skutečnou logiku. Rovnováha: emulujte vnější svět, provádějte testovanou skutečnou logiku.
Testovatelnost a AI
Existuje zajímavá zpětná vazba: kód, který se těžko testuje, je často špatně navržený kód. Pokud má AI problémy se zápisem testů do funkce (příliš mnoho závislostí, skrytý globální stav, vedlejší efekty), je to nepříjemný design. Zeptat se AI „jak byste refaktorovali tento kód, aby byl testovatelný“ vede k lepšímu testování a lepšímu kódu.
Parametrizované testy a diverzita dat
Psaní samostatného testu pokaždé za účelem ověření stejného pravidla s různými vstupy je zdlouhavé a náročné na údržbu. Parametrizované testování – struktura, která opakovaně spouští stejnou testovací logiku na seznamu vstupů a očekávaných výsledků – toto opakování eliminuje: jediné testovací tělo je napájeno desítkami vstupních párů. Umělá inteligence je velmi efektivní při vytváření těchto tabulek očekávaných výsledků, když jí dáte svá pravidla přijetí; Zejména systematicky sepisuje mezní hodnoty a třídy ekvivalence.
Ale i zde je past: AI má tendenci odvozovat očekávané výsledky ve vygenerované tabulce z testovaného kódu. Tato chyba je ještě nebezpečnější při parametrizovaném testování, protože jediná nesprávná logika znehodnotí desítky řádků. Nechte si proto vždy nezávisle vypočítat sloupec očekávaného výsledku podle akceptačního pravidla a ručně ověřte alespoň pár řádků. Požádejte také o sloupec popisu „co každý řádek představuje“; takže když se řada přeruší, okamžitě uvidíte, který stav je přerušený.
Tip: Záměrně přidejte „řádek pasti“ do parametrizované testovací tabulky – to znamená, že vědomě přepište výsledek. Pokud se tento řádek při spuštění testu nezbarví červeně, váš test ve skutečnosti tuto situaci neověřuje. Toto je rychlá kontrola předstírání.
Slabá výzva / Silná výzva
Slabé: "Napište test jednotky pro tuto funkci."
Silný: Napište testy jednotek [jazyk/rámec] pro funkci "taxCalculate(částka, sazba). Pravidlo přijetí: výsledek = částka * sazba, zaokrouhleno na 2 desetinná místa; záporná částka nebo sazba způsobí chybu; vrátí 0, pokud je sazba 0. Použijte strukturu AAA. Ručně vypočítejte očekávané hodnoty podle TĚCHTO pravidel; neodkazujte na aktuální výstup funkce a zaokrouhlete na záporná čísla. každého testu popsat pravidlo, které ověřuje Externí závislost "Ne."
Výkonná výzva; Poskytuje pravidlo přijetí, nezávislé očekávání očekávané hodnoty, strukturu a okrajové případy. Test se tak stává strážcem pravidla, nikoli zrcadlem kódu.
Tabulka kvality testů jednotek
symptom
Špatný test (falešná důvěra)
dobrý test
tvrdit
Žádné nebo „není null“
Očekávaná konkrétní hodnota
Očekávaný zdroj hodnoty
Výstup funkce
Akceptační pravidlo / ruční výpočet
závislost
Aktuální DB/síť/hod
Izolované s maketou/stub
okrajové pouzdro
Pouze šťastná cesta
limit, zápor, chyba
Když porušíte kód
zůstává zelená
zčervená
Jméno
test1, testMetoda
popisuje pravidlo, které potvrzuje
Čtyři kopírovatelné šablony
1) Testování jednotky řízené pravidly:
Vaše role: vedoucí softwarový testovací inženýr. Napište jednotkový test na následující funkci pomocí [jazyk/rámec]: [podpis]. Pravidla přijetí: [pravidla].- Použijte strukturu AAA.- Ručně vypočítejte očekávané hodnoty podle TĚCHTO pravidel; NEODKAZUJTE na aktuální výstup funkce. - Pokryjte limit, zápor, chybu a šťastnou cestu samostatnými testy. - Nechte každý název testu popsat pravidlo, které ověřuje. - Vysmívat se externím závislostem; Aby skutečná logika fungovala.
2) Kontrola mutační odolnosti:
Podívejte se na tyto testy jednotek. Uveďte 5 menších úprav, které bych mohl provést v testovaném kódu (a - místo +, a >= místo >, posun hranice) a u každého mi řekněte, KTERÝ z těchto testů zčervená? Pokud nejsou vráceny žádné, test je nedostatečný. Kód + testy: [vložit]
3) Kontrola testovatelnosti:
Proč je obtížné napsat unit test pro tuto funkci? Skrytá závislost, globální postavení, vedlejší účinky, existuje mnoho povinností? Navrhněte minimální refaktoring, aby byl testovatelný; neměňte chování. Kód: [vložit]
4) Neúplné dokončení scénáře:
Jsou uvedeny následující funkce a dostupné testy. Uveďte, které chování/hrana nebylo NIKDY testováno (mezera rozsahu) a přidejte pro každé test. Funkce+testy: [vložit]
tři mini pouzdra
Případ 1 – Test zrcadlení kódu. Vývojář nechal AI napsat test pro funkci zaokrouhlování; 10 testů bylo zelených. Ve skutečnosti se funkce zaokrouhlovala špatným směrem, ale AI převzala očekávané hodnoty z výstupu funkce, takže testy považovaly chybu za „pravdivou“. Když byly očekávané hodnoty ručně vypočteny pomocí šablony „řízené pravidly“, 4 testy zčervenaly a byla odhalena skutečná chyba.
Případ 2 — Hodnota kontroly mutace. Jeden tým spoléhal na 45 jednotkových testů. Vyzkoušeno 20 drobných úprav kódu pomocí „kontroly robustnosti mutace“; testy zachytily pouze 11 z nich. Zbývajících 9 přerušení proběhlo v tichosti. Tým posílil slabé testy; Tyto rozšířené testy v příštím vydání zachytily skutečnou chybu ve výpočtu.
Případ 3 – Netestovatelnost je vůně designu. AI nemohla psát testy pro objednávkovou funkci, neustále potřebovala skutečnou databázi. "Testability review" šablona ukázala, že funkce vestavěné databáze přístupu. Když bylo vložení závislosti odstraněno, mohly být zapsány testy a kód se stal čistším.
Časté chyby
- Odvození očekávané hodnoty z kódu. AI přijme výstup funkce jako „správný“; test, který potvrdí chybný kód.
- Test bez tvrzení nebo s triviálním tvrzením. "Nehodil chybu, prošel" logika; Nic to nepotvrzuje.
- Extrémní výsměch. Zesměšňování všeho a testování pouze toho, co falešný vrátí; skutečná logika není testována.
- Prostě šťastná cesta. Obcházení limitních, záporných a chybových stavů.
- Netestování porušením kódu. Důvěřovat zelené bez kontroly mutace.
- Ignorování netestovatelnosti. Nerozpoznávání a opravování špatného designu místo nátlaku na testování.
V souhrnu
Jednotkové testy jsou nejrychlejší a největší vrstvou testovací pyramidy; Zachytí chybu v nejlevnější chvíli. Umělá inteligence je velmi schopná produkovat unit testy, ale jejím největším úskalím je psaní testů, které předpokládají nesprávné chování jako „správné“ odvozením očekávané hodnoty ze samotného kódu. Řešení: dejte pravidla přijetí, nechte si ručně vypočítat očekávané hodnoty, prosazujte principy AAA a FIRST, zesměšňujte vnější svět a spusťte skutečnou logiku a otestujte každý test mutací (prolomením kódu). Kód, který se obtížně testuje, je znakem návrhu, který je třeba opravit.
Aplikační úkol
Vyberte funkci, která obsahuje obchodní pravidlo z vašeho vlastního projektu. Napište pravidla přijetí a nechte si AI napsat testy pomocí šablony „testování jednotek řízených pravidly“; Nechte si ručně vypočítat očekávané hodnoty. Poté použijte „kontrolu robustnosti mutace“: udělejte v kódu alespoň 5 malých přerušení a změřte, kolik testů zčervená. Přidejte nový test na nezachycená poškození. Uveďte, kolik narušení bylo zachyceno (například skóre mutací).
kontrolní seznam
- [ ] Dal jsem pravidla akceptace a nechal očekávané hodnoty vypočítat ručně.
- [ ] Ujistil jsem se, že testy neodvozují očekávanou hodnotu z kódu.
- [ ] Zavedl jsem nezávislé testování podle pokynů AAA a FIRST.
- [ ] Zesměšnil jsem externí závislosti a spustil skutečnou logiku.
- [ ] Zabýval jsem se limitními, negativními a chybovými případy.
- [ ] Prolomením kódu (mutací) jsem dokázal, že testy skutečně chrání.