Od UNIT testů očekáváme, že ověří správnost upravené logiky a pomohou odhalit nechtěné změny v chování aplikace. Při vývoji s AI je navíc zásadní kontrolovat, že zůstaly zachované i funkce mimo rozsah zadání.
Ověřit, že nová funkce funguje, je proto jen část práce. Musíme také zkontrolovat, zda změna nenarušila stávající pravidla aplikace.
Co mají Unit testy chránit
Jednotkové testy ověřují chování jednotlivých částí kódu. Zároveň slouží jako pojistka proti regresím — chybám vzniklým změnou chování, které dříve fungovalo.
U kódu vytvořeného AI je tato ochrana obzvlášť cenná. AI může splnit konkrétní požadavek a přitom změnit i logiku, která měla zůstat nedotčená.
Dobře navržené testy pomáhají vymezit hranice změny:
Toto chování chceme změnit. Tato pravidla musí platit i nadále.
Testujte podle rizika a skutečných závislostí
Není potřeba automaticky psát samostatný test pro každý getter, setter nebo jednoduchou datovou třídu.
Test, který pouze opakuje implementaci, může zvýšit počet testů, aniž by přinesl výraznější hodnotu. Při dalších změnách navíc přidává práci s údržbou.
Praktické pravidlo zní:
U konkrétní změny se zaměřte na upravované chování a na části aplikace, které na něm závisejí. Rozsah testování určujte podle možných dopadů.
U jednoduchých metod bez rozhodovací logiky nemusí být samostatný jednotkový test nutný, pokud jejich chování dostatečně pokrývají jiné testy.
Samotná jednoduchost ale není důvodem předpokládat, že AI neudělá chybu. I jednořádková metoda může určovat cenu objednávky nebo přístupová oprávnění uživatele.
Než přidáte test, položte si tři otázky:
1. Jaké chování se v tomto úkolu mění?
Ověřujeme, že změna splňuje zadání.
2. Která pravidla a závislé komponenty musí zůstat zachované?
Hledáme místa, kde by změna mohla způsobit regresi.
3. Zachytí test skutečnou chybu?
Ověřujeme očekávané chování, místo abychom jen kopírovali implementaci.
Testy musí navazovat na business logiku
Nejhodnotnější jednotkové testy chrání konkrétní pravidla aplikace.
U metody pro výpočet slevy například nestačí zkontrolovat, že vrací číslo. Potřebujeme vědět, zda stále platí tato pravidla:
- Sleva nepřekročí povolený limit.
- Výsledná cena neklesne pod nulu.
- Zákazník, který na slevu nemá nárok, zaplatí plnou cenu.
- Výpočet dodržuje stanovená pravidla zaokrouhlování.
Právě propojení metody s konkrétním obchodním pravidlem dává testu smysl.
Implementace se může změnit. Pravidlo, které leží mimo zamýšlený rozsah úkolu, musí zůstat zachované.
Jak k tomu přistupuje AITM
AITM propojuje vývoj s AI s kontextem projektu, kontrakty a závislostmi mezi jednotlivými částmi aplikace.
Před implementací architekt určí, co se má změnit, jak jsou příslušné části propojené a která pravidla musí zůstat zachovaná. Z těchto informací následně vychází testovací krok v pipeline.
Zásadní otázkou tedy není jen to, zda AI umí napsat test. Důležité je, zda ví, co má test chránit a proč.
Uvažujme změnu metody DiscountService.calculateDiscount(). Pokud kontrakt pomocí dependsOnModules zaznamenává, že na výpočtu slevy závisí také OrderSummary.render(), má testovací krok důvod prověřit i dopad na souhrn objednávky.
Samotný výpočet lze ověřit jednotkovým testem. Pro kontrolu spolupráce výpočtu se souhrnem objednávky může být vhodnější integrační test.
Testy se tedy navrhují podle skutečných závislostí a rizik konkrétní změny.
Deset testů pro jeden úkol, dva tisíce pro jiný
Každý úkol nepotřebuje stejný rozsah testování.
Pro ilustraci: v projektu s 32 467 testy může drobná změna vyžadovat spuštění deseti relevantních testů. Změna sdílené business logiky jich může vyžadovat dva tisíce.
Cílem zacíleného testování je vybrat testy, které pokryjí upravené chování a jeho závislosti. To může zkrátit dobu do získání zpětné vazby a soustředit ověřování na rizika daného úkolu.
Širší regresní kontroly nebo kompletní sada testů mají stále své místo při rozsáhlých změnách nebo před vydáním nové verze.
Počet spuštěných testů má odpovídat dopadu změny.
Když test selže, musíme pochopit proč
Neúspěšný test neznamená vždy stejný problém. Je potřeba rozlišovat mezi těmito situacemi:
- Do implementace se dostala chyba.
- Změna neúmyslně porušila existující obchodní pravidlo.
- Nová funkce záměrně změnila očekávané chování a test je potřeba aktualizovat.
Kontext pro toto posouzení poskytují požadavky úkolu, kontrakty a popisy business logiky.
Pokud se požadavek oprávněně změnil, musí se změnit i odpovídající test. Pokud AI porušila pravidlo, které mělo zůstat zachované, je potřeba opravit implementaci.
Pouhá úprava testu tak, aby znovu prošel, může skutečnou chybu skrýt.
Jednotkové testy jsou první vrstvou ochrany
Každá úroveň testování má jinou roli:
- Jednotkové testy ověřují jednotlivé části logiky.
- Integrační testy ověřují spolupráci modulů a systémů.
- E2E testy kontrolují celé uživatelské scénáře v běžící aplikaci.
Tyto vrstvy se doplňují. Každá zachytí jiné typy chyb a pomáhá ověřit změnu z jiného pohledu. Jejich použití v AITM popisuje dokumentace Testování.
Při vývoji s AI proto kontrolujeme dvě věci: zda byl úkol splněn a zda zůstalo zachované chování mimo jeho zamýšlený rozsah.
Propojení požadavků úkolu, business logiky, závislostí a testů je důležitou součástí orchestrace v AITM.
Ukázka jednotkových testů.
Více informací na www.aitm.cz.
#AITM #UnitTesting #SoftwareTesting #AI #SoftwareDevelopment
Zdroj: Unit Tests as a safeguard against unintended changes — AITM – AI Task Manager, LinkedIn