Testy z telefonu, včetně kritérií pokrytí
Šest úrovní testů, kritéria pokrytí od příkazů po MC/DC a proč je výsledky mít v telefonu výhoda.
Záložka Projekt → Testy není jen výpis toho, co padá. Je to místo, kde testy zadáváte, čtete jejich historii a proklikáte se od padajícího případu k tomu, co vlastně ověřuje — a to všechno z telefonu, bez jediného řádku promptu.
Úrovně
Testy jsou rozdělené do šesti úrovní: unit, integrační, systémové, E2E, výkon UI a výkon backendu. Přepínají se nahoře a každá si drží vlastní historii Běhů.
To dělení není kosmetické. Padající unit test znamená něco jiného než padající E2E — a když vidíte obojí v jednom seznamu, ztratíte právě tu informaci, kvůli které se testy dělí.
Kritéria pokrytí — a proč vůbec
Když si necháte testy napsat větou „napiš testy“, dostanete testy. Otázka je, co ověřují — a na to nemá nikdo odpověď, dokud něco nepadne v produkci.
Kritérium pokrytí je pravidlo, které říká, kdy je testů dost. Není to procento; je to věta, která se dá zkontrolovat:
- Pokrytí příkazů
- Každý příkaz se aspoň jednou provede. Nejlevnější a nejslabší — kód se spustil, ale o jeho větvích to neříká nic.
- Pokrytí větví
- Každá podmínka vyjde jednou pravdivě a jednou nepravdivě. Tady začínají testy nacházet chyby.
- MC/DC
- U každé dílčí podmínky se ukáže, že sama o sobě mění výsledek. Drahé, ale u složených podmínek je to jediný způsob, jak zjistit, že jedna z nich je tam navíc.
- Pair-wise
- Každá dvojice hodnot z různých charakteristik se sejde aspoň v jednom testu. Zlomek kombinací, většina chyb.
V aplikaci si kritérium vyberete při zadávání testů a vidíte u něj, jak je náročné — dřív, než Agent začne pracovat. To je ten rozdíl oproti „napiš testy“: víte, co dostanete, a Agent ví, kdy má přestat.
Přehled kritérií pro váš projekt si nechte sestavit Agentem. Doplní u nich, jak jsou náročná právě tady — jiné jsou u parseru a jiné u formuláře.
Proč je to výhoda mít v telefonu
- Výsledky se čtou i bez spojení. Běhy jsou stažené, takže se v nich hrabete i v letadle.
- Od padajícího případu vede proklik na jeho popis v dokumentaci a na snímek obrazovky z okamžiku pádu. Ne na sto řádků logu.
- Historie napříč Běhy ukáže nestabilní test — ten, co jednou projde a podruhé ne. V terminálu si ho pamatujete, tady je vidět.
- Naměřené hodnoty u výkonnostních testů mají průběh napříč Běhy. Jedno číslo o měření neříká nic, směr ano.
- Zadání dalších testů je pár klepnutí, ne psaní promptu. Vybere se úroveň a kritérium, zbytek udělá Agent.
Odkud se výsledky berou
Aplikace čte JUnit XML, tedy formát, který umí vyplivnout skoro každý testovací nástroj. Agent ho zapíše do projektu a telefon si ho stáhne se zrcadlem — žádná služba mezi tím, žádné nahrávání nikam.
Tvar, ve kterém se výsledky zapisují, určuje aplikační skill. Skilly se do projektu vkládají ze záložky Projekt, sekce Aplikační skilly; bez nich uvidíte jen to, co už v projektu je.
Zaseklo se to jinde, než co je tady? Napište na support@coden-app.com.