Co je test a proč ho potřebujete

Claude Code změnil kód a napsal: "Testy prošly". Za touhle krátkou větou se skrývají soubory s kontrolami, příkaz ke spuštění a konkrétní výsledky. Nejdřív se podíváme na druhy testování a na to, co lze ověřit ručně, pak rozebereme automatický test a význam jeho výsledku.

K tomu nám stačí malý příklad s přidělováním bodů. Testovací knihovny nemusíte znát předem: nejprve projdeme scénář ručně, potom stanovíme očekávání pro automatické testy a přečteme si zprávu o jejich spuštění.

Druhy testování

Testování pomáhá zjistit, jak se program chová, zda odpovídá požadavkům a kde vznikají problémy. Například jestli se správně přidělují body, zda lze odeslat žádost s prázdným polem nebo jestli je chybová zpráva srozumitelná. Zvolíme podmínky kontroly, provedeme kroky a prohlédneme si výsledek.

Testování lze rozdělit podle různých hledisek. Začněme tím, kdo provádí kroky a kontroluje výsledek:

• ruční testování - člověk provede kontrolu sám a vyhodnotí výsledek;
• automatizované testování - část kontrol svěříme programu: ten provede zadané kroky a porovnání. Těmto kontrolám se obvykle říká automatické testy nebo autotesty.

Tohle je rozdělení podle způsobu provedení. Je tu ale i další otázka: co přesně kontrolujeme. Funkční kontroly se týkají chování: například zda byly přiděleny správné body. Nefunkční se týkají vlastností aplikace, třeba rychlosti odezvy nebo snadnosti používání. Tato hlediska na sobě nezávisí: stejnou funkci lze kontrolovat ručně i automaticky.

Automatizace člověka nenahrazuje. Pořád je třeba vybrat užitečné scénáře, stanovit očekávání a porozumět zjištěným rozdílům. Jen opakující se část práce provádí program.

Co je ruční testování

Při ručním testování provádíte kroky sami a sledujete, zda výsledek odpovídá očekávání. Testovací kód psát nemusíte. Potřebujete srozumitelné podmínky a otázku, na kterou chcete odpovědět.

Představte si, že na výukovém portálu náleží za každou shodu 10 bodů, tedy za tři shody 30 bodů. Přidělování můžete ručně ověřit takto:

1. otevřete správnou verzi portálu a připravte uživatele s nulovým zůstatkem, kterému ještě nebyla přidělena odměna;
2. připravte žádost se třemi shodami a odešlete ji jednou;
3. po odeslání se podívejte na zůstatek: očekává se 30 bodů;
4. zaznamenejte skutečný výsledek. Pokud je číslo jiné, poznamenejte si kroky a případně pořiďte snímek obrazovky.

Počáteční zůstatek je důležitý. Pokud na něm už bylo 20 bodů, po přičtení očekáváte 50, nikoli 30. Bez vstupních podmínek snadno zaměníte správný výsledek za chybu nebo naopak.

Výsledek kontroly se vyplatí zapsat stručně: "Zůstatek před odesláním 0, tři shody, jedno odeslání, očekáváno 30, získáno 3". Z takového záznamu jiný člověk nebo Claude Code pochopí, co má zopakovat. Věta "body fungují nějak divně" to nevysvětluje.

Ruční testování může být i průzkumné: aplikaci zkoumáte a průběžně vymýšlíte nové kontroly. Třeba si všimnete, že tlačítko zůstane po odeslání aktivní, a rozhodnete se vyzkoušet opakované kliknutí. Nemáte předem rozepsanou trasu pro každý krok, ale cíl zůstává: porozumět chování a zaznamenat objevené problémy. Nejde o nahodilé klikání.

Nástroje jsou přitom naprosto v pořádku. Můžete otevřít konzoli prohlížeče, prohlédnout si odpověď serveru, pořídit snímek obrazovky nebo si vést seznam kontrol. "Ruční" znamená, že kontrolu řídí a výsledek vyhodnocuje člověk, ne že pracuje bez nástrojů.

Ruční kontrola se hodí, když potřebujete prozkoumat nové chování nebo posoudit, zda je rozhraní srozumitelné. Automatická je užitečná pro opakování popsaných kroků a porovnání. Není to pevné rozdělení na "rozhraní jen ručně, výpočty jen kódem": i kroky v prohlížeči lze automatizovat a výpočet ověřit ručně.

Když kliknete na tlačítko pro spuštění autotestů, nejde ještě o ruční testování: po spuštění provádí kontroly program. Pokud vám ale Claude Code připraví seznam kroků, podle kterého sami projdete portál a vyhodnotíte výsledek, kontrola zůstává ruční. Agent vám ji pomohl připravit.

Co je automatický test

Představte si, že kontrolujete kalkulačku. Zadáte 2 + 2, předem očekáváte 4 a porovnáte číslo na obrazovce s tímto očekáváním. Pokud vidíte 5, víte, že výsledek pro tento příklad není správný. Správnou odpověď znáte nezávisle na tom, co kalkulačka ukázala.

Automatický test provádí podobnou práci programově. Je to malý program, který nastaví vstupní podmínky, provede akci a ověří výsledek. Porovnání místo člověka provádí kód. Dál budeme takovému automatickému testu říkat jednoduše test.

Vraťme se k portálu s odměnami: jedna shoda přináší 10 bodů, za tři náleží 30. Kontrolu lze popsat slovy:

1. nastavit počet shod: 3;
2. vypočítat odměnu;
3. ověřit, že výše odměny je 30.

A tohle bude jeden test. Má předem známý příklad a očekávanou odpověď. Pravidlo "10 bodů za shodu" platí pro náš výukový portál; v jiné aplikaci může být jiné.

Test sám nevymyslí, kolik bodů má uživatel dostat. Někdo musí vzít pravidlo z požadavků a zapsat očekávání. Může to udělat vývojář nebo Claude Code na vaše zadání, ale správnost očekávání je pořád potřeba ověřit podle požadavku.

Proč kontrolu opakovat

Jednorázová ruční kontrola přidělování bodů je docela snadná. Problém se objeví později: přidáte nový druh odměny, změníte zpracování žádosti nebo požádáte agenta, aby zjednodušil funkci. Po každé takové úpravě se vrací stejná otázka: dávají tři shody pořád 30 bodů?

Pokaždé můžete znovu připravit žádost, provést kroky a zkontrolovat výsledek. Nebo si kontrolu zapíšete do kódu a spustíte ji znovu. Za stejných připravených podmínek test zopakuje zadané kroky a porovnání. Bez dalšího vysvětlování, kam kliknout a co považovat za správné.

S růstem projektu přibývá podobných pravidel. Žádost bez shod nesmí přidat body; opakovaná žádost se nesmí započítat dvakrát; seznam odměn musí mít určité pořadí. Kontroly můžete spustit společně a zjistit, které očekávání po změně přestalo platit.

V tom spočívá přínos automatizace: opakovaná kontrola popsaného chování vyžaduje méně ruční práce. I psaní testů zabere čas a při změně požadavků je třeba je upravit. U pravidel, ke kterým se stále vracíte, se ale tato práce vyplatí díky opakovaným spuštěním.

Kde jsou testy uložené

Testy jsou v běžných souborech projektu. V malém projektu v JavaScriptu je šikovné uložit kontrolu vedle kódu, který volá:

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

V souboru reward-flow.js je výpočet odměny. reward-flow.test.js obsahuje kód, který tento výpočet zavolá a ověří odpověď. Soubor package.json popisuje nastavení projektu a příkazy, včetně příkazu pro testy.

Část názvu .test.js napoví, že jde o soubor s kontrolami. Je to konvence podporovaná testovacími nástroji, nikoli samostatné pravidlo jazyka JavaScript. V jiných projektech se používají jiné názvy nebo samostatná složka tests/. Jeden soubor může obsahovat více testů; samostatný testovací soubor ke každému zdrojovému souboru není nutný.

Pokud Claude Code pracuje v neznámém projektu, požádejte ho, aby nejprve našel existující test přidělování bodů a ukázal jeho cestu. Kontrolu tak můžete přiřadit ke správnému chování, i když se zatím nevyznáte ve všech složkách.

Jak záměr převést na kontrolu

Pokyn "oprav přidělování bodů a ověř ho testy" nechává agentovi dvě otázky: co považovat za správné přidělení a jak výsledek potvrdit. Lepší je začít chováním, kterého chcete dosáhnout. Například: "Za každou shodu náleží 10 bodů. Za tři shody má odměna činit 30 bodů."

Takový záměr lze převést na kontrolu bez jediného řádku kódu. Popište tři věci:

Lze to vyjádřit jednou větou: "Pokud jsou tři shody, výpočet odměny má vrátit 30 bodů." To stačí k diskusi o smyslu testu. Jak kontrolu v tomto projektu zapsat do kódu, už zjistí agent.

Je důležité vybrat, co přesně chcete potvrdit. "Vypočtená odměna je 30" a "zůstatek uživatele se změnil na 30" jsou různá očekávání. Pro druhé potřebujete počáteční zůstatek a akci, která body přičítá, stejně jako při ruční kontrole výše. Proto je lepší nahradit pokyn "ověř body" přesným pozorovatelným výsledkem.

Pak promyslete i související situace. Pro naše pravidlo stačí začít s malou tabulkou:

Není třeba hned vymýšlet desítky případů. Začněte problémovým scénářem a několika souvisejícími případy, kterých se změna mohla dotknout. Pokud není jasné, co se má stát třeba při opakovaném odeslání žádosti, nejprve si ujasněte pravidlo. Agent může navrhnout variantu, ta ale ještě není potvrzeným očekáváním.

Jak zadat kontrolu Claude Code

Když je očekávané chování popsané, můžete práci uspořádat podle něj. Agent nejprve zjistí, jaké kontroly už v projektu jsou, a pak je porovná s vašimi scénáři. Potřebný test už může existovat: pak je důležité ho spustit a přečíst si výsledek. Pokud chybí, agent bude muset test doplnit.

První zadání může vypadat takto:

Oprav výpočet odměny.
Pravidlo: za každou shodu se přiděluje 10 bodů.
Ověřované případy: 3 shody dávají 30 bodů,
0 dává 0 a 5 dává 50.

Před změnami najdi existující kontroly těchto případů.
Stručně popiš, co se už ověřuje, co chybí
a které testy navrhuješ přidat nebo upravit.
Pokud jsou požadavky nejasné, uveď to.
Zatím soubory neměň.

Odpověď čtěte jako popis budoucího výsledku. Vycházejí čísla ve všech případech z vašeho pravidla? Kontroluje se opravdu výše odměny, nebo něco jiného? Nenavrhuje agent změnu samotného pravidla, aby odpovídalo současnému chování? V této fázi upřesňujete zadání, nemusíte kvůli tomu číst implementaci testu.

Po upřesnění scénářů zadejte pokyn k provedení práce:

Oprav výpočet podle dohodnutého pravidla.
Doplň chybějící kontroly odsouhlasených případů
a použij nástroje zavedené v projektu.
Neměň existující očekávání jen kvůli úspěšnému běhu.
Pokud se domníváš, že je očekávání chybné, nejprve vysvětli proč.

Spusť potřebné testy podle pokynů projektu.
Ukaž příkaz, pracovní složku a skutečný výstup.
U každého ze tří případů uveď, který test ho ověřil
a jak skončil. Přeskočené a nespuštěné kontroly
vypiš zvlášť.

Příkaz ke spuštění agent najde v dokumentaci a nastavení projektu. V projektech v JavaScriptu to často bývá npm test: npm spustí příkaz z pole scripts.test v souboru package.json. Pod tímto názvem se může skrývat různá sada kontrol. Vaším úkolem je ověřit, že spuštění zahrnulo potřebné scénáře.

Napsaný a spuštěný test jsou dvě různé fáze práce. Zpráva "přidal jsem tři kontroly" potvrzuje pouze změny v souborech. K posouzení výsledku je potřeba skutečné spuštění. Pokud ho nelze provést, například kvůli chybějící závislosti, agent má uvést, co tomu bránilo a které kontroly zůstaly neprovedené.

V odpovědi hledejte spojení "náš scénář → konkrétní test → výsledek". Pokud se ze tří dohodnutých případů provedl jen jeden, zatím je potvrzený pouze ten. I kdyby byl závěrečný řádek zelený.

Jak číst výsledek

Níže je skutečný běh jednoho výukového testu na Node.js 20.18.0 a npm 10.8.2. Ověřuje pouze výpočet odměny za tři shody, nikoli celou výše navrženou sadu scénářů. Kvůli přehlednosti jsme odstranili časové údaje a část technického výpisu:

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

První dva řádky ukazují balíček a spuštěný příkaz. Pod nimi je název testu. Řádek ok 1 znamená, že test číslo 1 prošel; u neúspěšného testu začíná řádek naopak not ok. Řádky pass 1 a fail 0 říkají, že jeden test prošel a žádný neselhal. Tomu se říká "zelený" výsledek, i když terminál text neobarví.

Ve variantě s chybou vychází za tři shody odměna 3 body, přestože podle pravidla má být 30. Tentýž test vypíše tento úryvek; cesta, zásobník volání, čas a část technických řádků jsou vynechané:

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

Nejprve najděte název testu a pak porovnejte expected a actual. První znamená "očekáváno", druhé "skutečný výsledek". Tady se očekávalo 30, ale získali jsme 3. Řádek fail 1 shrnuje výsledek: jeden test selhal.

Takové selhání znamená, že skutečný výsledek neodpovídá zapsanému očekávání. Teď je potřeba zjistit proč: může jít o chybu ve výpočtu, nesprávné vstupní údaje nebo chybné očekávání v samotném testu. Číslo v kontrole neměňte jen kvůli úspěšné zprávě; nejprve ověřte pravidlo.

Může nastat i jiné selhání: test například nedokázal načíst soubor s funkcí. K porovnání bodů se vůbec nedostal a ve výpisu nemusí být ani název daného testu; jako neúspěšný se označí celý soubor. Proto samotný řádek fail 1 nestačí k závěru "výpočet je chybný". Podívejte se na zprávu nad souhrnem.

Přeskočený test

Test může mít ještě jeden důležitý stav. Kontrola může být označena jako přeskočená; v Node.js se to dělá například pomocí test.skip. Takový test se neprovede. To, že je jeho název ve výpisu, ještě neznamená, že se scénář ověřil.

Při samostatném spuštění našeho příkladu se přeskočený test projevil takto:

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

Všimněte si nezvyklého detailu: řádek začíná na ok, ale končí na # SKIP. Takto tento formát označuje přeskočení. Řídit se jen prvním slovem nestačí; souhrnný údaj pass 0 potvrzuje, že žádný test neprošel.

Srovnejme tři spuštění téhož scénáře:

Ve větších výpisech najdete i další řádky. V našich spuštěních jsou cancelled a todo rovny nule. Pokud vidíte nenulové hodnoty, zjistěte, které testy byly zrušené nebo označené jako nedokončené; nepočítejte je mezi úspěšně ověřené. Řádek suites se vztahuje ke skupinám testů; v našem příkladu žádné nejsou.

A ještě drobnost. Pokud výpis ukazuje nula testů, absence selhání nepotvrzuje správné přidělování. Potřebná kontrola se nemusela do spuštění dostat. Název scénáře a počet provedených kontrol jsou důležitější než celkový dojem z barvy terminálu.

Co znamená zelený výsledek

Test z ukázaného výpisu odpověděl na úzkou otázku: "Je odměna za tři shody vypočítaná správně?" Neověřoval případ bez shod, opakovanou žádost ani číslo na stránce. Tyto případy se nestanou ověřenými jen proto, že jsme je zmínili v zadání.

Pro ověření případu bez shod potřebujete další scénář se samostatným očekáváním 0. Chcete-li ověřit opakovanou žádost, musíte popsat právě opakovanou akci a její očekávaný výsledek. Test tato pravidla neodvodí ze sousedního kódu. Ověřuje jen to, co je v něm zapsáno.

Chybějící test se liší od přeskočeného. Přeskočený test je ve výpisu vidět jako skipped. O scénáři, pro který se test vůbec nenapsal, výpis obvykle nic neříká. Všechny existující testy mohou projít, přestože neověřené chování obsahuje chybu.

Nakonec: úspěšné porovnání samo o sobě neznamená, že je správné i očekávání. Kdybychom pro naše pravidlo chybně zapsali 3 místo 30 a výpočet vrátil 3, porovnání by prošlo. Při návrhu kontroly proto odpovězte na dvě otázky: jaké chování test ověřuje a odkud pochází očekávaný výsledek.

Věta "testy prošly" je užitečná, pokud rozumíte jejím hranicím. Informuje o úspěšném provedení konkrétních kontrol při konkrétním spuštění. Nevyplývá z ní slib, že "aplikace už nemá žádné chyby".