GraphQL testovanie: Ako odhaliť chyby, ktoré REST testeri prehliadajú

Autor:  Katarína Kučáková

Kariéra • 13 min. čítania • 12. 5. 2026

Autor:  Katarína Kučáková •

Kariéra • 13 min. čítania • 12. 5. 2026

GraphQL testovanie má jednu zradnú vlastnosť: API ti pri chybe často odpovie HTTP 200 OK. Status kód nestačí – chyby sa skrývajú v tele odpovede. Na rozdiel od REST API nemá tento dopytovací jazyk desiatky endpointov, ale jeden jediný, do ktorého klient posiela vlastné queries. Tento návod ťa prevedie od základných konceptov, cez bezpečnostné riziká, až po praktické testovanie na reálnom API.

Čo je GraphQL?

GraphQL je dopytovací jazyk (query language) pre API, ktorý vyvinul Facebook v roku 2015. Od roku 2018 je open-source projekt spravovaný GraphQL Foundation. Základná myšlienka je jednoduchá: klient si presne určuje, aké dáta chce získať – nie server.

Na rozdiel od klasického REST API, kde každý endpoint vracia pevne definované polia, GraphQL umožňuje v jednej požiadavke získať len tie údaje, ktoré skutočne potrebuješ. Ak chceš profil používateľa s menom a emailom, vráti presne tieto polia. Ak potrebuješ aj zoznam jeho príspevkov, zahrnúť ich môžeš do toho istého query. Tento prístup odstraňuje over-fetching (príliš veľa dát) aj under-fetching (nutnosť volať ďalšie endpointy).

Pre testerov je kľúčové, že všetky požiadavky prechádzajú jedným endpointom – zvyčajne /graphql. To zásadne ovplyvňuje celý prístup k plánovaniu a pokrytiu testovania.

GraphQL ako dopytovací jazyk

Query language je jadro GraphQL – umožňuje klientom presne definovať, aké dáta chcú získať, a server vráti len tieto polia, nič viac, nič menej. V praxi to znamená, že jeden dopyt môže nahradiť viacero REST volaní, čo zvyšuje efektivitu prenosu dát a zjednodušuje testovanie.

Vnorené požiadavky sú ďalšou silnou stránkou: klient môže načítať súvisiace dáta naraz. Napríklad jedným dopytom je možné získať používateľa spolu s jeho príspevkami a komentármi, presne špecifikovať požadované polia a filtrovať to, čo nie je potrebné.

Takto vyzerá základné query v praxi:

query {
  user(id: "1") {
    id
    name
    email
    posts {
      id
      title
    }
  }
}

Klient načíta používateľa s ID 1 a zároveň jeho príspevky. Server vráti len požadované polia – žiadny zbytočný prenos dát.

Základné operácie: Query, Mutation, Subscription

GraphQL rozlišuje tri typy operácií, pričom každá má jasne definované správanie a zodpovedajúcu sémantiku:

• GraphQL query slúži na čítanie dát – ekvivalent HTTP GET. Umožňuje vyžiadať konkrétne polia jedného objektu alebo zoznamu.
• GraphQL mutation slúži na zmenu dát: vytváranie, úpravu alebo vymazanie záznamov. Je ekvivalentom POST, PUT a DELETE v REST.
• GraphQL subscription umožňuje aktualizácie v reálnom čase cez WebSocket. Testovanie subscriptions si vyžaduje špeciálny prístup – ide o kontinuálny tok dát.

Takto vyzerá rovnaká operácia zapísaná ako query a ako mutation:

# Query – načítanie používateľa
query {
  user(id: "1") {
    id
    name
    email
  }
}

# Mutation – zmena mena používateľa
mutation {
  updateUser(id: "1", name: "Jana Nová") {
    id
    name
  }
}

Schema, typy a introspection

Schéma v GraphQL je kontrakt medzi klientom a serverom. Definuje, aké typy dát v API existujú, aké operácie sú dostupné a ako sú dáta navzájom prepojené. Na rozdiel od REST tu nie je dokumentácia zvonku – schéma je priamo súčasťou API a je vždy aktuálna.

Silné typovanie znamená, že každé pole má presne definovaný typ. Nástroje to využívajú na validáciu queries ešte pred odoslaním – ak sa pýtaš na pole, ktoré neexistuje, dostaneš chybu okamžite, nie až z produkcie.

Pre testerov je mimoriadne dôležitá vlastnosť nazývaná GraphQL introspection (schopnosť API opísať vlastnú schému). Nástroje ako GraphiQL alebo Postman ju využívajú na automatické zobrazenie všetkých dostupných operácií, parametrov a typov – vždy aktuálna dokumentácia priamo v testovacom prostredí, bez nutnosti spoliehať sa na Wiki alebo Confluence.

GraphQL vs REST – hlavné rozdiely z pohľadu testera

Väčšina porovnaní REST a GraphQL sa sústreďuje na perspektívu vývojára. Z pohľadu testovania sú však kľúčové konkrétne dôsledky pre overovanie a kontrolu dát. Porovnanie sa oplatí aj pri rozhodovaní o testovacej stratégii.

Testeri zvyknutí na REST sa pri prvom kontakte s GraphQL stretávajú s troma typickými pascami:

1. Sledujú HTTP status kód a považujú odpoveď za úspešnú. GraphQL pritom vracia HTTP 200 aj pri chybe, skutočný stav je skrytý v poli errors v tele odpovede.
2. Predpokladajú fixnú štruktúru odpovede ako v REST. Každý klient si však v GraphQL skladá vlastnú query, takže rovnaký endpoint vracia zakaždým iné dáta.
3. Testujú endpoint ako jednotku – v GraphQL jeden endpoint pokrýva celé API, takže pokrytie testmi musíš stavať cez kombinácie polí a operácií, nie cez zoznam URL.

Testovanie10 min.

2. 10. 2023

REST API: Kľúč k efektívnej komunikácii pri vývoji softvéru

V tomto článku ti popíšeme čo je REST API, ako funguje, prečo je dôležité a ako pomáha pri vývoji softvéru.

Najväčší dopad na to, ako pristupuješ k testovaniu, majú štyri rozdiely:

• Jeden endpoint vs. viacero endpointov: REST umožňuje rozdelenie testovacích scenárov podľa endpointov a HTTP metód. Na strane GraphQL sú všetky požiadavky centralizované na jeden endpoint, čo vyžaduje komplexnejší prístup pri overovaní rôznych dopytov a kombinácií polí.
• Flexibilita dopytov: Klient si presne definuje, ktoré polia má server vrátiť. Pri testovaní musíš pokryť rôzne kombinácie voliteľných a vnorených dátových štruktúr.
• Chybové správy: Každý dopyt vracia HTTP 200 OK, aj keď nastala chyba. Chyby sú v poli errors v odpovedi – kontrola len HTTP status kódu môže viesť k prehliadnutiu problémov.
• Verzie API: REST často používa explicitné verziovanie, zatiaľ čo tento štandard sa spolieha na kompatibilnú schému. Nové polia môžu byť pridané bez zmeny endpointu, čo si vyžaduje pozornosť pri regresnom testovaní.

Voľba medzi REST a GraphQL závisí od charakteru dát a klientov. REST je vhodnejší pre jednoduché CRUD operácie a API s aktívnym HTTP cachingom. Tento prístup sa oplatí pri komplexných dátových modeloch, mobilných aplikáciách s obmedzenou šírkou pásma a rýchlo sa meniacich produktoch. Mnohé moderné systémy využívajú kombináciu oboch prístupov.

Ako testovať GraphQL API

Testovanie tohto typu API si vyžaduje špecifický prístup, pretože všetky dopyty a mutácie prechádzajú jedným endpointom a odpovede sú flexibilné. Nižšie sú hlavné oblasti, ktoré by mali byť pokryté v každom testovacom pláne.

Testovanie Query a Mutation

Základné funkčné testovanie GraphQL API zahŕňa overenie, že queries vracajú správne dáta a že mutations skutočne vykonávajú zmeny. Konkrétne treba pokryť:

• Overenie správnosti odpovede: Porovnaj vrátené polia s očakávanou schémou a dátami.
• Testovanie čiastočných queries: Opýtaj sa len na podmnožinu polí a over, že odpoveď obsahuje presne to, čo si požadoval.
• Vnorené queries: Tento dopytovací jazyk umožňuje hlboko vnorené štruktúry. Testuj, že vzťahy medzi entitami fungujú správne (napr. príspevky autora vrátane komentárov).
• Validácia chybových odpovedí: Úmyselne pošli neplatný query a over, že odpoveď obsahuje pole errors s popisom. HTTP status bude stále 200.
• Edge cases: Prázdne polia, null hodnoty, neexistujúce identifikátory, prázdne zoznamy.

Takto vyzerá chybová odpoveď GraphQL pri neplatnom query – HTTP status je 200, chyba je skrytá v tele:

# Neplatné query – pole neexistuje v schéme
query {
  user(id: "1") {
    id
    nonExistentField
  }
}

# Odpoveď servera (HTTP 200!)
{
  "errors": [
    {
      "message": "Cannot query field 'nonExistentField' on type 'User'.",
      "locations": [{ "line": 4, "column": 5 }]
    }
  ],
  "data": null
}

Schema validácia a introspection testing

Základom celého GraphQL API a zároveň jeden z najdôležitejších predmetov testovania je schéma. Schema validácia odhaľuje tzv. breaking changes – zmeny, ktoré spôsobia, že existujúce queries prestanú fungovať. Ak vývojár premenuje alebo odstráni pole zo schémy, pokazia sa všetky klientské aplikácie, ktoré ho využívajú.

Praktický postup: Stiahni snapshot schémy cez introspection query pred nasadením a po ňom. Porovnaj oba snapshoty – akákoľvek nekompatibilná zmena by mala byť zachytená ako zlyhanie testu, nie až ako hlásenie z produkcie.

Tento krok sa dá plne automatizovať v CI/CD pipeline a odporúčame ho nasadiť čo najskôr – je to jedna z najefektívnejších poistiek proti neúmyselnému rozbitiu API pri nasadzovaní.

Bezpečnostné testovanie GraphQL

Oproti REST API prináša GraphQL špecifické bezpečnostné riziká, ktoré sú oveľa menej výrazné alebo neexistujú vôbec. Každý tester by mal poznať nasledujúce typy útokov a vedieť ich otestovať:

• Introspection v produkcii: Ak je introspection povolená na produkčnom prostredí, útočník získa kompletný prehľad o schéme vrátane interných typov. Over, že na produkcii je introspection vypnutá.
• Deep query attack: Útočník pošle extrémne hlboko vnorenú query s desiatkami úrovní. Testuj, či server obmedzuje maximálnu hĺbku query.
• Batch query attack: Štandardne je tu umožnené posielanie viacerých operácií v jednom requeste. Over, či je nastavený limit počtu operácií v jednej dávke.
• Query complexity limity: Každé pole v query pridáva výpočtovú záťaž. Testuj, či server odmietne príliš komplexné queries ešte pred ich vykonaním.
• Rate limiting: Over, že rate limiting funguje zmysluplne aj pre GraphQL, nielen pre HTTP endpointy.

Výkonnostné testovanie GraphQL API

Variabilita GraphQL requestov znamená, že rôzne kombinácie polí môžu mať dramaticky odlišné časy odpovede. Jednoduchý query na meno užívateľa a komplexný query na celú sieť jeho vzťahov idú na ten istý endpoint, ale ich náročnosť je neporovnateľná.

Známa výkonnostná pasca je N+1 problém. Pri načítaní zoznamu 100 príspevkov server vykoná 100 samostatných requestov do databázy na načítanie autora každého z nich – výsledok je 101 databázových queries namiesto 2. Riešenie (DataLoader pattern) existuje, ale musíš otestovať, či je skutočne nasadené a či resolver zvláda efektívne agregovať dáta.

Pre výkonnostné testy GraphQL API odporúčame nástroje k6, JMeter alebo Artillery.

Kariéra10 min.

29. 12. 2023

Úvod do performance testingu

Objav základy výkonnostného testovania, typy, nástroje a odporúčania pre lepší výkon tvojich aplikácií.

Nástroje na testovanie GraphQL

Výber nástroja závisí od fázy testovania – či ide o manuálne preskúmanie, automatizované regresné testy alebo záťažové testy. Tu je prehľad najpopulárnejších možností pre testovanie GraphQL:

Odporúčame ti…

Pre tímové prostredie odporúčame začať s nástrojom Postman, ktorý väčšina testerov pozná z REST API testovania. Postman podporuje GraphQL natívne a umožňuje zdieľať kolekcie queries v tíme.

Ak testuješ aj SOAP API v projektoch, pozri sa na SoapUI návod. Pre správu API dokumentácie je relevantný aj Swagger pre QA – hoci sa primárne používa pre REST, kombinovaná znalosť oboch štandardov ti dá komplexnejší pohľad na API testovanie.

Nástroje ako Postman alebo Altair pokrývajú manuálne a základné automatizované testovanie. V praxi sa čoraz častejšie využívajú aj end-to-end nástroje – API testing v Cypress napríklad umožňuje testovať toto API nepriamo cez UI alebo priamo cez sieťové requesty.

Testovanie GraphQL API v praxi: hands-on tutoriál

Skôr než s GraphQL začneš, je dobré ho vnímať ako súčasť širšieho kontextu pre testovanie webových aplikácií, kde sa API testy kombinujú s UI a end-to-end scenármi. V kontexte full-stack testovanie pokrýva logiku a dátovú vrstvu backend testovanie. Najlepší spôsob, ako pochopiť toto testovanie, je vyskúšať si ho na reálnom API.

Na tento účel použijeme verejné GraphQLZero API (graphqlzero.almansi.me) – bezplatné, bez registrácie, ideálne pre učenie. Rovnaký postup funguje pre akékoľvek API v tvojich projektoch.

Krok 1: Preskúmaj schému cez introspection

Otvor GraphQL Playground alebo GraphiQL na adrese GraphQLZero API. Klikni na tlačidlo Schema alebo Docs v pravom paneli – nástroj automaticky spustí introspection query a zobrazí všetky dostupné typy, operácie a parametre.

Hľadáš: zoznam dostupných query a mutation, parametre každej operácie, typy návratových hodnôt a to, či sú polia povinné alebo nepovinné. Toto je základ pre zostavenie testovacieho plánu.

Krok 2: Spusti a over základnú query

Napíš jednoduchú query na konkrétneho užívateľa – požiadaj o jeho id, meno, email a adresu. Spusti query a skontroluj odpoveď. Over štyri veci: HTTP status je 200, pole data obsahuje objekt user, všetky požiadané polia majú hodnoty a pole errors v odpovedi neexistuje.

query {
  user(id: "1") {
    id
    name
    email
    address {
      city
      zipcode
    }
  }
}

Teraz query úmyselne rozbi – opýtaj sa na pole, ktoré neexistuje. Odpoveď stále vráti HTTP 200, ale bude obsahovať pole errors s popisom chyby. Toto je základný reflex, ktorý si musíš vypestovať: vždy kontroluj telo odpovede, nielen status.

Krok 3: Otestuj mutation

Vytvor nový záznam cez mutation – napríklad nový príspevok s názvom, body a ID autora. Over, že odpoveď obsahuje ID nového záznamu a že pole errors neexistuje.

mutation {
  createPost(input: {
    title: "Testovací príspevok",
    body: "Obsah príspevku pre testovanie.",
    userId: "1"
  }) {
    id
    title
  }
}

Potom pošli mutation s neplatným vstupom – napríklad bez povinného parametra. Odpoveď musí obsahovať errors pole s popisom toho, čo je neplatné. Každú mutation testuj s platným vstupom, neplatným vstupom aj hraničnými hodnotami (extrémne dlhý text, špeciálne znaky, null hodnoty).

Krok 4: Bezpečnostný spot-check

Otestuj, či je introspection povolená – na produkčnom prostredí by mala byť vypnutá. Pošli nasledujúcu introspection query:

query {
  __schema {
    types {
      name
    }
  }
}

# Na produkčnom prostredí by server mal odpovedať:
# { "errors": [{ "message": "GraphQL introspection is not allowed..." }] }
# Ak vráti zoznam typov, introspection je zapnutá – bezpečnostný nález!

Skús poslať aj extrémne hlboko vnorenú query – ak server neobmedzuje hĺbku, trvá dlho alebo sa zastaví, je to ďalší bezpečnostný problém na nahlásenie.

Odporúčame ti…

Pre hlbšie štúdium odporúčame oficiálnu GraphQL dokumentáciu a Apollo Server testing docs.

Zdieľaj článok

GraphQL testovanie: Ako odhaliť chyby, ktoré REST testeri prehliadajú

O autorovi

Katarína Kučáková

Software Test Engineer

Moja cesta k testovaniu softvéru sa začala v roku 2019 až po štúdiu ekonómie a pracovných skúsenostiach v iných odvetviach. To mi pomohlo vnímať IT svet v rôznych súvislostiach. Ten totiž ponúka neustále nové výzvy, pre ktoré rada hľadám riešenia. Obľubujem oddych pri čítaní, turistiku alebo lyžovanie. LinkedIn