Čo je test a prečo ho potrebujeme

Claude Code upravil kód a napísal: "Testy prešli". Za touto krátkou vetou sú súbory s kontrolami, príkaz na spustenie a konkrétne výsledky. Najprv si ukážeme, aké druhy testovania existujú a čo možno overiť manuálne, potom rozoberieme automatický test a význam jeho výsledku.

Stačí nám na to malý príklad s prideľovaním bodov. Testovacie knižnice nemusíte poznať vopred: najskôr prejdeme scenár manuálne, potom sformulujeme očakávania pre automatické testy a pozrieme sa na správu o ich vykonaní.

Aké druhy testovania existujú

Testovanie pomáha zistiť, ako sa program správa, či spĺňa požiadavky a kde vznikajú problémy. Napríklad, či sa správne prideľujú body, či možno odoslať formulár s prázdnym poľom alebo či je chybové hlásenie zrozumiteľné. Vyberieme podmienky kontroly, vykonáme akcie a preskúmame výsledok.

Testovanie možno rozdeliť podľa rôznych kritérií. Začnime tým, kto vykonáva akcie a kontroluje výsledok:

• manuálne testovanie - človek sám prejde kontrolu a vyhodnotí výsledok;
• automatizované testovanie - časť kontrol zveríme programu: vykoná zadané akcie a porovnania. Takéto kontroly sa zvyčajne nazývajú automatické testy alebo skrátene autotesty.

Ide o rozdelenie podľa spôsobu vykonania. Je tu aj ďalšia otázka: čo presne sa kontroluje. Funkčné kontroly sa týkajú správania, napríklad či sa pripísal správny počet bodov. Nefunkčné kontroly sa týkajú vlastností aplikácie, napríklad ako rýchlo odpovedá alebo nakoľko sa pohodlne používa. Tieto kritériá sú nezávislé: tú istú funkciu možno kontrolovať manuálne aj automaticky.

Automatizácia neodstraňuje účasť človeka. Stále treba vybrať užitočné scenáre, určiť očakávania a preskúmať nájdené rozdiely. Opakujúcu sa časť práce jednoducho vykoná program.

Čo je manuálne testovanie

Pri manuálnom testovaní vykonávate akcie sami a sledujete, či výsledok zodpovedá očakávaniu. Nemusíte pritom písať kód testu. Potrebujete jasné podmienky a otázku, na ktorú chcete odpovedať.

Predstavme si, že na učebnom portáli patrí za každú zhodu 10 bodov, čiže za tri zhody 30. Pridelenie bodov môžete manuálne overiť takto:

1. otvorte správnu verziu portálu a pripravte používateľa s nulovým zostatkom, ktorému ešte nebola pridelená odmena;
2. pripravte žiadosť s tromi zhodami a odošlite ju raz;
3. po odoslaní skontrolujte zostatok: očakáva sa 30 bodov;
4. zapíšte skutočný výsledok. Ak vyšlo iné číslo, zaznamenajte postup a prípadne urobte snímku obrazovky.

Počiatočný zostatok je dôležitý. Ak na ňom už bolo 20 bodov, po pridelení očakávate 50, nie 30. Bez vstupných podmienok ľahko označíte správny výsledok za chybu alebo naopak.

Výsledok kontroly sa dá stručne zapísať takto: "Zostatok pred odoslaním 0, tri zhody, jedno odoslanie, očakávalo sa 30, získali sme 3". Podľa takého záznamu iný človek alebo Claude Code pochopí, čo treba zopakovať. Veta "body fungujú čudne" to nevysvetľuje.

Manuálne testovanie môže byť aj prieskumné: skúmate aplikáciu a priebežne vymýšľate nové kontroly. Napríklad si všimnete, že tlačidlo zostáva dostupné aj po odoslaní, a rozhodnete sa vyskúšať opakované kliknutie. Nemáte vopred rozpísaný postup pre každý krok, no cieľ zostáva: pochopiť správanie a zaznamenať nájdené problémy. Nie iba bezcieľne klikať.

Nástroje sú pritom úplne v poriadku. Môžete otvoriť konzolu prehliadača, pozrieť odpoveď servera, urobiť snímku obrazovky alebo si viesť zoznam kontrol. Slovo "manuálne" znamená, že kontrolu riadi a výsledok vyhodnocuje človek, nie že pracuje bez nástrojov.

Manuálna kontrola sa hodí, keď skúmate nové správanie alebo chcete posúdiť, či je rozhranie zrozumiteľné. Automatická kontrola je užitočná na opakované vykonávanie už opísaných akcií a porovnaní. Nie je to striktné delenie na "rozhranie iba manuálne, výpočty iba kódom": aj akcie v prehliadači možno automatizovať a výpočet možno overiť manuálne.

Keď stlačíte tlačidlo na spustenie automatických testov, ešte nejde o manuálne testovanie: kontroly po spustení vykonáva program. Ak vám Claude Code zostaví zoznam krokov a vy podľa neho sami prejdete portál a vyhodnotíte výsledok, kontrola zostáva manuálna. Agent vám ju pomohol pripraviť.

Čo je automatický test

Predstavte si, že kontrolujete kalkulačku. Zadáte 2 + 2, vopred očakávate 4 a porovnáte číslo na obrazovke s týmto očakávaním. Ak vidíte 5, je jasné, že pre tento príklad je výsledok nesprávny. Správnu odpoveď poznáte bez ohľadu na to, čo ukázala kalkulačka.

Automatický test robí podobnú prácu programovo. Je to malý program, ktorý nastaví vstupné podmienky, vykoná akciu a skontroluje výsledok. Namiesto človeka vykoná porovnanie kód. Ďalej budeme takýto automatický test nazývať jednoducho testom.

Vráťme sa k portálu s odmenami: jedna zhoda prináša 10 bodov, za tri patrí 30. Kontrolu možno slovne zapísať takto:

1. nastaviť počet zhôd: 3;
2. vypočítať odmenu;
3. skontrolovať, či výška odmeny zodpovedá 30 bodom.

A toto bude jeden test. Obsahuje vopred známy príklad a očakávanú odpoveď. Pravidlo "10 bodov za zhodu" platí pre náš učebný portál; v inej aplikácii môže byť iné.

Test sám nevymyslí, koľko bodov má používateľ dostať. Niekto musí prevziať pravidlo z požiadaviek a zapísať očakávanie. Môže to urobiť vývojár alebo Claude Code na vaše zadanie, no zmysel očakávania treba aj tak overiť podľa úlohy.

Prečo kontrolu opakovať

Raz manuálne overiť prideľovanie bodov je celkom jednoduché. Problém sa objaví neskôr: pridáte nový druh odmeny, zmeníte spracovanie žiadosti alebo požiadate agenta, aby zjednodušil funkciu. Po každej takej úprave sa vynorí tá istá otázka: dávajú tri zhody stále 30 bodov?

Žiadosť môžete zakaždým pripraviť odznova, vykonať akcie a pozrieť výsledok. Alebo túto kontrolu zapísať do kódu a spustiť ju znova. Pri rovnakých pripravených podmienkach test zopakuje zadané akcie a porovnanie. Netreba znovu vysvetľovať, kam kliknúť a čo sa považuje za správne.

Keď projekt rastie, takýchto pravidiel pribúda. Žiadosť bez zhôd nesmie pridať body; opakovaná žiadosť sa nesmie započítať dvakrát; zoznam odmien má mať určené poradie. Kontroly možno spustiť naraz a zistiť, ktoré očakávanie sa po zmene prestalo plniť.

V tom spočíva prínos automatizácie: opakovaná kontrola už opísaného správania si vyžaduje menej manuálnej práce. Písanie testov tiež zaberie čas a pri zmene požiadaviek ich treba upraviť. Pri pravidlách, ku ktorým sa stále vraciate, sa však táto práca vyplatí opakovaným spúšťaním.

Kde sa testy nachádzajú

Testy sú uložené v bežných súboroch projektu. V menšom JavaScriptovom projekte je praktické umiestniť kontrolu vedľa kódu, ktorý volá:

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

V súbore reward-flow.js je výpočet odmeny. Súbor reward-flow.test.js obsahuje kód, ktorý tento výpočet zavolá a skontroluje odpoveď. Súbor package.json opisuje nastavenia projektu a príkazy vrátane príkazu na testy.

Časť názvu .test.js pomáha rozpoznať súbor s kontrolou. Je to konvencia podporovaná testovacími nástrojmi, nie samostatné pravidlo jazyka JavaScript. V iných projektoch sa používajú odlišné názvy alebo samostatný priečinok tests/. Jeden súbor môže obsahovať viac testov; samostatný testovací súbor pri každom zdrojovom súbore nie je povinný.

Ak Claude Code pracuje v neznámom projekte, požiadajte ho, aby najprv našiel existujúci test prideľovania bodov a ukázal jeho cestu. Tak môžete porovnať kontrolu s požadovaným správaním, aj keď sa ešte nevyznáte vo všetkých priečinkoch.

Ako premeniť zámer na kontrolu

Prosba "oprav prideľovanie a over ho testami" necháva agentovi dve otázky: čo sa považuje za správne pridelenie a čím potvrdiť výsledok. Lepšie je začať správaním, ktoré očakávate. Napríklad: "Za každú zhodu patrí 10 bodov. Pri troch zhodách má byť odmena 30".

Takýto zámer možno premeniť na kontrolu bez jediného riadka kódu. Opíšte tri veci:

Dá sa to zhrnúť do jednej vety: "Ak sú tri zhody, pri výpočte odmeny má vyjsť 30 bodov". To stačí na diskusiu o zmysle testu. Agent zistí, akým kódom kontrolu v tomto projekte zapísať.

Je dôležité vybrať, čo presne chcete potvrdiť. "Vypočítala sa odmena 30" a "zostatok používateľa sa zvýšil na 30" sú odlišné očakávania. Na druhý prípad treba poznať počiatočný zostatok a akciu, ktorá body pripíše, ako pri manuálnej kontrole vyššie. Preto je lepšie nahradiť slová "skontroluj body" konkrétnym pozorovaním.

Potom sa zamyslite nad súvisiacimi situáciami. Pre naše pravidlo stačí začať malou tabuľkou:

Nemusíte hneď vymýšľať desiatky prípadov. Začnite problematickým scenárom a niekoľkými súvisiacimi prípadmi, ktorých sa úprava mohla dotknúť. Ak nie je jasné, čo sa má stať, napríklad pri opakovanej žiadosti, najprv si ujasnite pravidlo. Agent môže navrhnúť možnosť, no ešte to neznamená, že ste sa na očakávaní dohodli.

Ako zadať kontrolu Claude Code

Keď sformulujete očakávané správanie, môžete podľa neho zorganizovať prácu. Agent najprv zistí, aké kontroly už v projekte existujú, a potom ich porovná s vašimi scenármi. Potrebná kontrola už možno existuje: vtedy ju treba spustiť a prečítať výsledok. Ak chýba, agent bude musieť pridať test.

Prvé zadanie môže vyzerať takto:

Treba opraviť výpočet odmeny.
Pravidlo: za každú zhodu sa prideľuje 10 bodov.
Kontrolované prípady: 3 zhody dávajú 30 bodov,
0 dáva 0, 5 dáva 50.

Pred úpravami nájdi existujúce kontroly týchto prípadov.
Stručne opíš, čo sa už kontroluje, čo chýba
a ktoré testy navrhuješ pridať alebo upraviť.
Ak sú požiadavky nejasné, uveď to.
Zatiaľ nemeň súbory.

Prečítajte si odpoveď ako opis budúceho výsledku. Vychádzajú čísla vo všetkých prípadoch z vášho pravidla? Kontroluje sa naozaj výška odmeny alebo niečo iné? Nenavrhuje agent zmeniť samotné pravidlo, aby zodpovedalo aktuálnemu správaniu? V tejto fáze spresňujete zadanie, preto nemusíte čítať implementáciu testu.

Po ujasnení scenárov zadajte agentovi samotnú prácu:

Oprav výpočet podľa dohodnutého pravidla.
Doplň chýbajúce kontroly dohodnutých prípadov
pomocou nástrojov používaných v projekte.
Nemeň existujúce očakávania len preto, aby testy prešli.
Ak si myslíš, že je očakávanie nesprávne, najprv vysvetli prečo.

Spusti potrebné testy podľa pokynov projektu.
Ukáž príkaz, pracovný priečinok a skutočný výstup.
Pri každom z troch prípadov uveď, ktorý test ho kontroloval
a ako sa skončil. Vynechané a nespustené kontroly
vypíš osobitne.

Agent nájde príkaz na spustenie v dokumentácii a nastaveniach projektu. V JavaScriptovom projekte je to často npm test: npm vykoná príkaz z poľa scripts.test v súbore package.json. Pod týmto názvom sa môže skrývať rôzna množina kontrol. Vašou úlohou je overiť, či sa spustili potrebné scenáre.

Napísaný test a vykonaný test sú dve odlišné fázy práce. Správa "pridal som tri kontroly" hovorí iba o zmenách v súboroch. Na vyhodnotenie výsledku treba testy naozaj spustiť. Ak to nejde, napríklad pre chýbajúcu závislosť, agent má uviesť, čo tomu zabránilo a ktoré kontroly zostali nevykonané.

V odpovedi hľadajte spojenie "náš scenár → konkrétny test → výsledok". Ak sa z troch prebratých prípadov vykonal iba jeden, zatiaľ je potvrdený len ten. Aj keď je záverečný riadok zelený.

Ako čítať výsledok

Nižšie je skutočné spustenie jedného učebného testu na Node.js 20.18.0 a npm 10.8.2. Kontroluje iba výpočet odmeny za tri zhody, nie všetky scenáre uvedené vyššie. Pre lepšiu čitateľnosť sme vynechali časové údaje a pomocné riadky správy:

> 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

Prvé dva riadky ukazujú balík a vykonaný príkaz. Nasleduje názov testu. Riadok ok 1 znamená, že test číslo 1 prešiel; pri neúspešnom sa začína na not ok. Riadky pass 1 a fail 0 hovoria, že jeden test prešiel a žiadny nezlyhal. Tomu sa hovorí "zelený" výsledok, aj keď terminál text farebne nezvýrazňuje.

Vo variante s chybou vyjde za tri zhody odmena 3 body, hoci podľa pravidla patrí 30. Ten istý test vypíše takýto úryvok; cesta, zásobník volaní, čas a časť pomocných riadkov sú 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

Najprv nájdite názov testu a potom porovnajte expected a actual. Prvé znamená "očakávalo sa", druhé "získalo sa". Tu sa očakávalo 30, získali sme 3. Riadok fail 1 zhŕňa výsledok: jeden test zlyhal.

Takéto zlyhanie znamená, že získaná hodnota sa nezhoduje so zapísaným očakávaním. Ďalej treba zistiť príčinu: chyba vo výpočte, nesprávne vstupné údaje alebo chybné očakávanie v samotnom teste. Číslo v kontrole nemožno meniť len kvôli úspešnej správe; najprv treba overiť pravidlo zo zadania.

Môže dôjsť aj k inému zlyhaniu: napríklad test nedokázal načítať súbor s funkciou. Potom sa vôbec nedostal k porovnaniu bodov a v správe nemusí byť ani názov požadovaného testu: ako neúspešný sa označí celý súbor. Preto samotný riadok fail 1 nestačí na záver "výpočet je nesprávny". Pozrite si správu nad súhrnom.

Vynechaný test

Test má aj ďalší dôležitý stav. Kontrola môže byť označená ako vynechaná; v Node.js sa to dá urobiť napríklad cez test.skip. Taký test sa nevykoná. To, že sa jeho názov objaví v správe, ešte neznamená, že sa scenár skontroloval.

Pri samostatnom spustení nášho príkladu vynechaný test vypísal tento riadok a súhrn:

ok 1 - three matches give 30 points # SKIP

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

Všimnite si nezvyčajný detail: riadok sa začína na ok, ale končí sa na # SKIP. Takto tento formát označuje vynechaný test. Nestačí orientovať sa iba podľa prvého slova; súhrn pass 0 potvrdzuje, že tu neprešiel žiadny test.

Porovnajme tri spustenia toho istého scenára:

Vo väčších správach sú aj ďalšie riadky. V našich spusteniach majú cancelled a todo hodnotu nula. Ak vidíte nenulové hodnoty, zistite, ktoré testy boli zrušené alebo označené ako nedokončené; nezapočítavajte ich medzi úspešne overené. Riadok suites sa týka skupín testov: v našom príklade žiadne skupiny nie sú.

Ešte jedna drobnosť. Ak správa ukazuje nula testov, neprítomnosť zlyhaní nepotvrdzuje správnosť prideľovania bodov. Požadovaná kontrola sa možno vôbec nespustila. Názov scenára a počet vykonaných kontrol sú dôležitejšie než celkový dojem z farby terminálu.

Čo znamená zelený výsledok

Test z ukážkovej správy odpovedal na úzku otázku: "Je odmena za tri zhody vypočítaná správne?" Nekontroloval nula zhôd, opakovanú žiadosť ani číslo na stránke. Tieto prípady sa nestanú overenými len preto, že sme ich spomenuli v zadaní.

Na kontrolu nula zhôd treba ďalší scenár so samostatným očakávaním 0. Ak chcete overiť opakovanú žiadosť, treba opísať práve opakovanú akciu a jej očakávaný výsledok. Test tieto pravidlá neodvodí zo susedného kódu. Kontroluje sa iba to, čo je v ňom zapísané.

Chýbajúci test nie je to isté ako vynechaný test. Vynechaný test je v správe označený ako skipped. O scenári, pre ktorý sa kontrola vôbec nenapísala, správa zvyčajne nič nehovorí. Všetky existujúce testy môžu prejsť, aj keď neoverené správanie obsahuje chybu.

Napokon, úspešné porovnanie ešte neznamená, že samotné očakávanie je správne. Ak pre naše pravidlo omylom zapíšeme 3 namiesto 30 a výpočet vráti 3, porovnanie prejde. Preto je pri diskusii o kontrole užitočné odpovedať na dve otázky: aké správanie test kontroluje a odkiaľ pochádza očakávaný výsledok.

Veta "testy prešli" je užitočná, ak poznáte jej hranice. Hovorí o úspešnom vykonaní konkrétnych kontrol pri konkrétnom spustení. Nevyplýva z nej sľub, že "v aplikácii už nie sú žiadne chyby".