Logo Light
Published on

Testování ukázkové API aplikace (1. díl) - Testovací plán - API

Úvod

V tomto článku ukážu, jak může vypadat testovací plán pro REST API postavené na Express.js, Prisma a JWT autentizaci. API obsahuje veřejné i chráněné endpointy, CRUD operace a základní autentizaci (registrace a login s pomocí JWT).

V tomto jednoduchém UI si můžete vyzkoušet, jaké služby API poskytuje.
Zde je URL pro API.
Pod následujícím linkem je Swagger dokumentace k API.
Zde je stručný popis testované aplikace.

Backend aplikace je napsaný v Express.js, jako databáze je použito Prisma/PostgreSQL, frontend je v Reactu. Backend i frontend je hostovaný na službě Vercel, databáze na službě Neon.

Repozitář pro backend: https://github.com/p-k-001/users-api
Repozitář pro frontend: https://github.com/p-k-001/users-ui

Projekt jsem vytvořil proto, abych měl hřiště pro hraní s nástroji pro automatizaci testování. Není to příklad, jak programovat API aplikaci :)

1. Cíl testování

Ověřit, že API endpointy fungují správně a bezpečně, a to jak při validních, tak i nevalidních požadavcích.

2. Rozsah testování

API zahrnuje:

  • Veřejné endpointy:

    • GET /hello – testovací odpověď

  • Chráněné endpointy (vyžadují JWT token):

    • POST /register – registrace nového uživatele
    • POST /login – přihlášení a získání JWT tokenu
    • POST /users – vytvoření uživatele
    • GET /users – výpis uživatelů
    • GET /users/:id – detail uživatele
    • PUT /users/:id – aktualizace uživatele
    • DELETE /users/:id – mazání konkrétního uživatele
    • DELETE /users – hromadné mazání všech uživatelů

API dále obsahuje:

  • Validace vstupních dat
  • Správné návratové kódy (400, 401, 403, 404, 500)
  • JWT autentizaci a autorizaci

Do rozsahu testování spadá:

  1. Funkční testy (pozitivní i negativní scénáře pro CRUD operace endpointu /users)
  2. Testování autentizace a autorizace
  3. Validace vstupů a ošetření chyb
  4. Kontrolu návratových kódů a odpovědí
  5. Základní testy CORS a bezpečnostních mechanismů
  6. Integraci s databází (Prisma)

Mimo rozsah testování je:

  • Nefunkční testy (výkon, škálování, ...)
  • Penetrační testy
  • UI, UX testy (není součástí API)

Úrovně testů

  1. Unit testy

    • Např. funkce isAdult, middleware authenticateToken, validace vstupů.

  2. Integrační testy

    • Testování jednotlivých endpointů proti testovací databázi.

  3. End-to-End (E2E)

    • Testování celého flow (registrace – login – volání chráněných endpointů)

3. Zdroje

Členové týmu

V rámci tohoto článku nebudu řešit konkrétní rozdělení rolí (QA, vývojář, DevOps). Předpokládáme, že testování provádí jeden tester nebo vývojář, který API implementoval.

V reálném projektu by zde byly uvedeny role (QA, vývojář, produktový manažer) a odpovědnosti.

Testovací nástroje

  • Jest pro automatizované unit testy
  • Playwright pro integrační a E2E testy

Testovací prostředí

  • Node.js verze: 20.11
  • Databáze: Postgres
  • Testovací prostředí oddělené od produkce
  • CI/CD pipeline (GitHub Actions)

Testovací data

  • Testovací uživatelé (validní i nevalidní)
  • JWT tokeny (platné, neplatné, expirované)
  • Nevalidní vstupní data (špatný formát e-mailu, záporný věk apod.)

4. Rizika

  • Neaktuální testovací prostředí (hrozí, že testy běží na jiné verzi API než produkce)
  • Závislost na databázi (pokud testovací DB není čistá, výsledky mohou být nekonzistentní)
  • Expirované tokeny během testu (některé scénáře mohou selhat, pokud není token platný)

5. Časová osa

Odhad pracnosti pro základní testy:

  • 8h: příprava testovacího prostředí (DB, nástroje)
  • 8h: implementace unit testů
  • 16h: integrační testy pro CRUD endpointy
  • 8h: E2E testy celého flow (registrace, login, CRUD)
  • 4h: Integrace do CI/CD pipeline
  • 4h: dokumentace výsledků

Celkem přibližně 6 dní práce pro jednoho QA/testera.

6. Výstupy

  • Testovací plán (tento dokument)
  • Sada automatizovaných testů (Jest + Playwright)
  • Test report (výsledky úspěšných a neúspěšných testů)
  • CI/CD integrace testů

7. Akceptační kritéria

  • Všechny klíčové testy (autentizace, CRUD) musí být PASSED (100 % úspěšnost).
  • API musí správně reagovat na:
    • Validní požadavky (status 200/201)
    • Nevalidní požadavky (status 400, 401, 403, 404)
  • Nesmí docházet k úniku chráněných dat bez JWT tokenu.
  • CORS konfigurace musí odpovídat whitelistu domén.
  • Nesmí být evidována žádná chyba se závažností CRITICAL

8. Použitá dokumentace

Testovací scénáře

Použité zkratky: POS - positivní scénář (správný průběh) NEG - negativní scénář (chybné nebo neautorizované požadavky)

1. Veřejné endpointy

1. Testovací endpoint

  1. GET /hello vrací {message: "Hello, API Testing!"} (POS)

2. Chráněné endpointy

1. Autentizace

  1. Registrace s validním e-mailem/heslem – 201 Created (POS)
  2. Registrace s existujícím e-mailem – 400 Email already exists (NEG)
  3. Registrace bez emailu/hesla – 400 Email and password are required (NEG)
  4. Registrace s nevalidním formátem emailu – 400 Invalid email format (NEG)
  5. Login s platnými údaji – 200 OK + JWT token (POS)
  6. Login se špatným heslem – 401 Invalid email or password (NEG)
  7. Login s neexistujícím účtem – 401 Invalid email or password (NEG)

2. GET /users

  1. Vrátí seznam uživatelů (když existují) (POS)
  2. Vrátí prázdné pole, pokud DB neobsahuje uživatele (POS)
  3. Vrátí uživatele podle platného ID – 200 OK (POS)
  4. Nevrátí uživatele podle platného ID pro cizího ownera – 404 User not found (NEG)
  5. Neexistující ID – 404 User not found (NEG)
  6. Neplatné ID (např. abc) – 400 Invalid ID (NEG)
  7. Bez JWT – 401 No token provided (NEG)
  8. S neplatným JWT – 403 Invalid token (NEG)

3. POST /users (chráněný endpoint)

  1. Vytvoření uživatele s platným JWT – 201 Created (POS)
  2. Bez JWT – 401 No token provided (NEG)
  3. S neplatným JWT – 403 Invalid token (NEG)
  4. Chybějící povinné pole – 400 validation errors (NEG)
  5. Nevalidní věk (např. -5) – 400 Age must be between 0 and 125 (NEG)
  6. Ověřit, že adult se správně počítá podle věku (méně než 18 – false, 18 a více – true) (POS)
  7. Chybějící name – 400 Name is required (NEG)
  8. Chybějící email – 400 Email is required (NEG)
  9. Nevalidní formát emailu – 400 Invalid email format (NEG)
  10. Chybějící age – 400 Age is required (NEG)

PUT /users/:id (chráněný endpoint)

  1. Aktualizace platného uživatele – 200 OK (POS)
  2. Aktualizace neexistujícího uživatele – 404 User not found (NEG)
  3. Aktualizace uživatele cizího ownera– 404 User not found (NEG)
  4. Neplatné ID – 400 Invalid ID (NEG)
  5. Nevalidní data (např. špatný formát emailu) – 400 (NEG)
  6. Aktualizace uživatele cizího ownera – (NEG)
  7. Bez JWT – 401 No token provided (NEG)
  8. S neplatným JWT – 403 Invalid token (NEG)

DELETE /users/:id (chráněný endpoint)

  1. Smazání existujícího uživatele – 204 No Content (POS)
  2. Smazání již smazaného uživatele – 404 User not found (NEG)
  3. Smazání uživatele cizího ownera – 404 User not found (NEG)
  4. Neplatné ID – 400 Invalid ID (NEG)
  5. Bez JWT – 401 No token provided (NEG)
  6. S neplatným JWT – 403 Invalid token (NEG)

DELETE /users (chráněný endpoint)

  1. Smazání všech uživatelů – 204 No Content (POS)
  2. Bez JWT – 401 (NEG)
  3. S neplatným JWT – 403 Invalid token (NEG)

JWT edge cases

  1. Expirace tokenu – 403 Invalid token (NEG)
  2. Poškozený token – 403 Invalid token (NEG)

CORS

  1. API akceptuje povolený origin http://localhost:5173 (POS)
  2. API odmítne nepovolený origin (NEG)

Slovníček

Rozdíl mezi autentizací a autorizací

  1. Autentizace (Authentication)

    • Ověření, kdo jsem.
    • Např. zadám e‑mail a heslo – server ověří, že opravdu existuji jako registrovaný uživatel.
    • Výsledek autentizace v tomto API je vydání JWT tokenu, pokud jsou přihlašovací údaje správné.

  2. Autorizace (Authorization)

    • Ověření, co smím dělat.
    • Když už mám platný JWT token, server kontroluje, jestli mám oprávnění přistoupit k určitému endpointu (např. chráněnému /users), případně jestli mám správnou roli (admin vs. user).

V kontextu tohoto API:

  • Autentizace je endpoint /login, který vydá token, když jsou údaje správné.
  • Autorizace je middleware authenticateToken, který kontroluje, zda je token platný, a pustí mě dál k chráněnému endpointu (POST /users, PUT /users/:id, …).