1. Testovací pyramida a strategie (FE vs. BE)
Aby byla automatizace efektivní, rozdělujeme testy podle vrstev architektury. Tím předcházíme vzniku nestabilních testů (flaky tests) a šetříme čas při jejich běhu v CI/CD.
Reálný kontext: Kdybychom všechno testovali tak, že robot reálně otevírá prohlížeč Chrome a proklikává web, trvaly by testy 2 hodiny. Díky rozdělení na vrstvy zjistíme 90 % chyb už na úrovni "strojové" komunikace za pár vteřin.
- Frontend (FE) Úroveň: Zaměřuje se na izolované testování komponent (UI), validaci vizuální stránky a klientské logiky bez přímé závislosti na živém BE (využíváme mockování).
- Reálný příklad: Testujeme čistě formulář. V kódu "podvrhneme" odpověď ze serveru (Mock). Zajímá nás jen to, zda se po zadání špatného e-mailu zobrazí na webu červená chybová hláška.
- Backend (BE) Úroveň: Zaměřuje se na rychlé a robustní testování byznys logiky (Unit testy) a správnost API endpointů (kontrola JSON schémat, HTTP status kódů).
- Reálný příklad: Serveru pošleme datový balíček (JSON) pomocí nástroje jako Postman nebo Mocha a kontrolujeme, zda nám server vrátí správný matematický výpočet nebo zda data správně uloží do databáze, aniž bychom vůbec potřebovali vidět grafiku webu.
- Integrace & E2E (End-to-End): Spojuje FE a BE dohromady. Simuluje reálnou IT návštěvu (např. volání API z frontendu, zápis do databáze, ověření třetích stran).
- Reálný příklad: Náš testovací robot zapne skutečný prohlížeč, klikne na tlačítko „Odeslat návštěvu“, počká na spojení se skutečnou databází a ověří, že zpráva opravdu dorazila na e-mail.
2. Rozšířená šablona automatizovaného Test Case
| Komponenta | Specifikace pro Frontend (UI) | Specifikace pro Backend (API / DB) |
|---|---|---|
| Test ID & Name | AUTO-FE-XXX (např. ověření UI elementu) | AUTO-BE-XXX (např. ověření API payloadu) |
| Prerequisites | Stav prohlížeče, localStorage, přihlášení. | Dostupnost databáze, vyčištění testovacích dat (Fixtures). |
| Test Steps (Act) | Interakce s UI (klik, zápis, výběr z menu). | Odeslání HTTP requestu (GET, POST), spuštění fronty. |
| Expected Results | Změna DOM stromu, viditelnost prvku, přesměrování. | HTTP Status (200, 201), validní JSON schéma, zápis v DB. |
Reálná ukázka z praxe – Jak se z kroku v tabulce stane kód:
- Špatně (nestabilní): Test hledá tlačítko podle barvy nebo pozice:
Klikni na třetí tlačítko zleva.(Pokud grafik změní rozložení, test spadne). - Profesionálně (stabilní): Programátor přidá do kódu neviditelnou jmenovku (Test-ID). Test ví přesně kam sáhnout:
await page.getByTestId('submit-visit-btn').click();.
3. Praktický příklad: Scénář pro IT návštěvu / Audit
Scénář: Schválení žádosti o IT návštěvu / API přístup.
| Vrstva | Test ID | Krok (Action) | Očekávaný výsledek (Assertion) |
|---|---|---|---|
| BE | AUTO-BE-102 | Pošli POST request na /api/v1/it-visit s platným JSON payloadem. | HTTP status 201 Created. Odpověď obsahuje visitId. |
| BE | AUTO-BE-103 | Proveď SELECT do databáze pro dané visitId. | Záznam existuje, stav žádosti v DB je nastaven na PENDING. |
| FE | AUTO-FE-401 | Otevři partnerskou zónu (API je mockované na stav PENDING). | Na obrazovce se vykreslí žlutý label „Čeká na schválení“. |
| E2E | AUTO-E2E-05 | Administrátor v UI schválí žádost → systém provede BE zápis → partnerovi se v UI okamžitě zpřístupní API klíče. | Flow proběhne bez mockování. Na konci skript ověří, že vygenerovaný klíč v UI je identický s klíčem v DB. |
Reálná ukázka (Jak to vypadá technicky):
V kroku AUTO-BE-102 náš automat odešle na server přesně tento datový balíček (JSON), což je strojový ekvivalent toho, jako by člověk vyplnil formulář:
JSON
{
"visitorName": "Firma XYZ",
"visitType": "API_AUDIT",
"date": "2026-10-15"
}
Očekávaný výsledek je, že server odpoví kódem 201 Created (což v IT řeči znamená „Úspěšně vytvořeno“) a vrátí nám unikátní ID této konkrétní návštěvy, například visitId: 98765.
4. Integrace do CI/CD (Continuous Integration / Continuous Deployment)
Automatizované testy mají smysl pouze tehdy, když běží autonomně při každé změně kódu. Naše CI/CD pipeline (např. GitLab CI, GitHub Actions) je rozdělena do fází (Stages), které fungují jako „brány“ (Quality Gates). Pokud kterákoliv fáze selže, nasazení do produkce se zastaví.
Reálný kontext: CI/CD je vlastně výrobní linka pro náš software. Vývojář nahraje novou úpravu (např. změní barvu hlavičky na webu) a tato linka se sama spustí. Nepotřebuje žádného člověka, aby testy zapnul.
Fáze CI/CD Pipeline pro FE a BE:
- Build Stage:
- Zkompiluje se kód pro Frontend i Backend.
- Spustí se linter (kontrola kvality a formátování kódu – hlídá, zda vývojáři píší kód čistě a bez překlepů).
- Unit & Component Test Stage:
- Spustí se izolované BE unit testy a FE komponentové testy.
- Proč tady? Běží extrémně rychle (vteřiny) a okamžitě odhalí chyby v syntaxi a základní logice. (Pokud rozbili kalkulačku uvnitř systému, zjistíme to za 3 vteřiny).
- Deploy to Staging / Test Env:
- Pokud unit testy projdou, aplikace se nasadí do izolovaného testovacího prostředí (Staging). Vše běží v Docker kontejnerech. (Docker kontejner si představte jako virtuální krabici, ve které běží identická kopie našeho webu, čistě pro účely testování, aniž bychom ovlivnili reálné zákazníky).
- API & E2E Test Stage:
- Proti živému Staging prostředí se spustí integrační API testy
AUTO-BE-XXXa následně komplexní End-to-End testyAUTO-E2E-XXXsimulující IT návštěvu v reálném prohlížeči (headless mode = prohlížeč reálně kliká na pozadí paměti serveru, i když nevykresluje obrazovku pro oči).
- Proti živému Staging prostředí se spustí integrační API testy
- Reporting & Deploy to Production:
- Výsledky testů se vygenerují do reportu (např. Allure Report).
- Pokud jsou všechny testy 100% zelené, pipeline automaticky (nebo po schválení) nasadí novou verzi do produkce k zákazníkům.
- Reálný příklad chyby: Pokud test selže (např. tlačítko „Odeslat“ chybí na obrazovce), nasazení se zablokuje. Vývojářský tým dostane okamžitě notifikaci do firemního Slacku. V této zprávě je odkaz, kde si vývojář může přehrát automaticky nahrané video toho, jak se náš robot na webu zasekl, a vidí přesně ten moment chyby.
