API testavimas su Playwright: praktinis gidas komandai

API testavimas su Playwright leidžia greitai patikrinti produkto verslo logiką, autorizaciją, duomenų validacijas ir integracijas be pilno naršyklės sluoksnio. Tai ypač naudinga tada, kai UI testai tampa per lėti, o komandai reikia ankstyvo signalo, ar pagrindiniai endpoint'ai veikia po pakeitimų.

Playwright dažnai siejamas su UI automatizavimu, tačiau jo APIRequestContext leidžia tame pačiame testavimo projekte siųsti HTTP užklausas, valdyti headers, cookies, token'us, ruošti testinius duomenis ir derinti API testus su realiais UI scenarijais.

Šiame gide parodysime, kada verta rinktis API testus vietoje UI scenarijų, kaip struktūruoti Playwright API testus, kaip tvarkyti autentikaciją, testinius duomenis, response validacijas ir kaip integruoti API testus į CI/CD procesą. Jei dar tik kuriate bendrą testavimo kryptį, verta pradėti nuo testų automatizavimo ir testavimo strategijos startupams.

Kas yra API testavimas?

API testavimas tikrina, kaip sistema veikia per programines sąsajas: endpoint'us, request parametrus, response struktūrą, status kodus, klaidų pranešimus, autorizaciją ir verslo taisykles. Skirtingai nei UI testai, API testai neatsidaro naršyklėje ir netikrina vizualaus vartotojo kelio.

Tai reiškia, kad API testas gali labai greitai atsakyti į klausimus:

• ar endpoint'as grąžina teisingą status kodą;
• ar response body turi laukus, kurių tikisi frontend arba kita sistema;
• ar skirtingos rolės gauna tik joms leidžiamus duomenis;
• ar validacijos veikia tiek teigiamuose, tiek neigiamuose scenarijuose;
• ar naujas backend pakeitimas nesugadino integracijos.

API testai neturėtų pakeisti visų UI testų. Jie papildo testavimo piramidę: daugiau logikos tikrinama žemesniame, greitesniame sluoksnyje, o UI testai paliekami svarbiausiems vartotojo keliams.

Kada API testai su Playwright duoda daugiausia vertės?

API testai su Playwright ypač vertingi tada, kai komandai reikia greito ir patikimo kokybės signalo. Jie padeda anksti pagauti backend, autorizacijos, duomenų ir integracijų klaidas, nelaukiant ilgesnio UI regression rinkinio.

API testus verta rašyti, kai:

• norite tikrinti kritinius endpoint'us po kiekvieno pull request;
• reikia validuoti roles, teises ir autentikaciją;
• turite CRUD operacijas, kurias brangu dengti tik per UI;
• frontend dar nestabilus, bet backend logika jau turi būti tikrinama;
• reikia greitai paruošti duomenis UI testams;
• sistema turi integracijų, microservice logikos arba svarbių webhook'ų;
• norite sumažinti per ilgą UI testų vykdymo laiką.

Jei turite daug lėtų UI testų, API sluoksnis dažnai yra pirmas geras optimizavimo taškas. Plačiau apie sluoksnių paskirstymą verta skaityti straipsnyje Unit, integration ir E2E testai.

API testai ar UI testai?

Dažna klaida — bandyti viską testuoti per UI. Toks kelias atrodo natūralus, nes imituoja realų naudotoją, bet jis brangus: naršyklė lėtesnė, scenarijai trapesni, o klaidos diagnostika dažnai sudėtingesnė.

Praktinė taisyklė: jei testuojate verslo taisyklę, validaciją arba teises — pradėkite nuo API. Jei testuojate vartotojo patirtį, formos veikimą arba realų pirkimo kelią — naudokite UI. Kritiniams srautams dažnai verta turėti abu sluoksnius.

Pirmas API testas su Playwright

Playwright API testai gali būti rašomi tame pačiame projekte kaip UI testai. Paprasčiausias GET testas atrodo taip:

import { test, expect } from '@playwright/test';

test('GET /users grąžina vartotojų sąrašą', async ({ request }) => {
  const response = await request.get('/api/users');

  expect(response.status()).toBe(200);
  expect(response.ok()).toBeTruthy();

  const body = await response.json();

  expect(Array.isArray(body)).toBeTruthy();
  expect(body.length).toBeGreaterThan(0);
  expect(body[0]).toHaveProperty('id');
  expect(body[0]).toHaveProperty('email');
});

Šis testas tikrina ne tik 200 OK, bet ir minimalų response turinį. Tai svarbu, nes status kodas vienas pats dar neįrodo, kad endpoint'as grąžino teisingus duomenis.

POST request pavyzdys

API testų vertė dar labiau matosi tada, kai reikia tikrinti veiksmus: objekto sukūrimą, validaciją arba klaidos scenarijų.

import { test, expect } from '@playwright/test';

test('POST /users sukuria naują vartotoją', async ({ request }) => {
  const uniqueEmail = `user-${Date.now()}@example.com`;

  const response = await request.post('/api/users', {
    data: {
      name: 'Test User',
      email: uniqueEmail
    }
  });

  expect(response.status()).toBe(201);

  const body = await response.json();

  expect(body.id).toBeTruthy();
  expect(body.email).toBe(uniqueEmail);
});

Realiame projekte tokį kodą verta perkelti į helper arba API client sluoksnį, kad testuose liktų verslo scenarijus, o ne techninės request detalės.

Request kontekstas ir bendra konfigūracija

Kai testų daugėja, svarbu nebekartoti to paties baseURL, headers ir login logikos kiekviename faile. Playwright leidžia bazinę konfigūraciją laikyti playwright.config.ts faile.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    baseURL: process.env.API_BASE_URL ?? 'https://example.com'
  }
});

Tada testuose galima naudoti santykinius kelius:

const response = await request.get('/api/users');

Didesniuose projektuose verta turėti atskirą API client sluoksnį:

export class UsersApi {
  constructor(private readonly request) {}

  async createUser(email: string) {
    return this.request.post('/api/users', {
      data: {
        name: 'Test User',
        email
      }
    });
  }

  async getUsers() {
    return this.request.get('/api/users');
  }
}

Tokia struktūra mažina dubliavimą ir leidžia keisti endpoint'us vienoje vietoje.

Autentikacija API testuose

API testuose autentikacija turi būti valdoma saugiai ir pakartotinai. Blogiausia praktika — hardcodinti slaptažodžius arba token'us tiesiai į testų failus.

Dažniausi variantai:

• bearer token per Authorization header;
• cookies arba storage state, kai API ir UI dalijasi sesija;
• login request testų setup etape;
• atskiri testiniai vartotojai skirtingoms rolėms;
• CI/CD secret'ai arba aplinkos kintamieji prisijungimams.

const response = await request.get('/api/profile', {
  headers: {
    Authorization: `Bearer ${process.env.API_TOKEN}`
  }
});

Jei testuojate roles, geriausia turėti aiškų vartotojų modelį: admin, standard user, readonly user ir unauthorized request. Taip API testai realiai tikrina saugumo ir prieigos taisykles, o ne tik endpoint'o gyvybingumą.

Ką validuoti API atsakymuose?

Geras API testas turi tikrinti tai, kas svarbu komandai ir produktui. Vien status kodo dažniausiai neužtenka, nes endpoint'as gali grąžinti 200, bet duomenys bus neteisingi.

API atsakymuose verta validuoti:

• status kodą;
• response body struktūrą;
• privalomus laukus;
• laukų tipus ir reikšmes;
• klaidų pranešimus neigiamuose scenarijuose;
• autorizacijos elgseną skirtingoms rolėms;
• verslo taisykles, pavyzdžiui limitus, statusų perėjimus arba kainos skaičiavimą.

Didesniuose projektuose verta naudoti bendrus assertion helperius arba schema validaciją, bet svarbu nepersistengti: testas turi būti suprantamas ir aiškiai parodyti, kokią riziką jis dengia.

Neigiami API scenarijai

API testai labai tinka neigiamiems scenarijams, nes juos dažnai sudėtinga arba brangu patikrinti per UI. Pavyzdžiui:

• request be privalomo lauko;
• neteisingas duomenų formatas;
• neautorizuotas request;
• vartotojas bando pasiekti svetimus duomenis;
• bandoma atlikti neleistiną statuso pakeitimą.

test('POST /users be email grąžina validacijos klaidą', async ({ request }) => {
  const response = await request.post('/api/users', {
    data: {
      name: 'Test User'
    }
  });

  expect(response.status()).toBe(400);

  const body = await response.json();

  expect(body.error).toContain('email');
});

Tokie testai dažnai pagauna daugiau realių backend ir autorizacijos problemų nei dar vienas ilgas UI scenarijus.

Testinių duomenų valdymas

Viena dažniausių API testų nestabilumo priežasčių yra blogai valdomi duomenys. Jei testas priklauso nuo aplinkoje jau egzistuojančio vartotojo, užsakymo ar statuso, jis tampa trapus.

Geresnė praktika:

1. susikurti duomenis prieš testą per API arba fixture;
2. naudoti unikalius identifikatorius, pavyzdžiui timestamp arba GUID;
3. neleisti testams priklausyti vienam nuo kito;
4. po testo išvalyti sukurtus objektus, jei tai būtina;
5. turėti atskirus testinius vartotojus skirtingoms rolėms;
6. CI/CD aplinkoje vengti priklausomybės nuo rankiniu būdu paruoštos būsenos.

Jei testinių duomenų valdymas nesutvarkytas, API testai greitai tampa tokie pat nestabilūs kaip prasti UI testai.

API testai kaip UI testų setup sluoksnis

Vienas praktiškiausių Playwright privalumų — API galima naudoti UI testų paruošimui. Vietoje to, kad per naršyklę pildytumėte ilgą registracijos arba užsakymo formą, galite reikalingą būseną susikurti per API ir UI teste tik patikrinti galutinį vartotojo kelią.

test('vartotojas mato sukurtą užsakymą UI', async ({ request, page }) => {
  const orderResponse = await request.post('/api/orders', {
    data: {
      productId: 123,
      quantity: 1
    }
  });

  const order = await orderResponse.json();

  await page.goto(`/orders/${order.id}`);

  await expect(page.getByText(order.id)).toBeVisible();
});

Tai sutrumpina UI testus, sumažina flaky žingsnius ir palieka naršyklę ten, kur ji tikrai reikalinga — vartotojo sąveikos patikrinimui.

Kaip organizuoti API testus didesniame projekte?

Pradžioje galima turėti kelis testų failus, bet augant projektui struktūra tampa svarbi. Aiški struktūra padeda išvengti dubliavimo ir leidžia komandai greičiau suprasti, kur ieškoti problemos.

tests/
  api/
    users.spec.ts
    orders.spec.ts
    auth.spec.ts
  ui/
    login.spec.ts
    checkout.spec.ts
fixtures/
  auth.fixture.ts
clients/
  users.api.ts
  orders.api.ts
utils/
  test-data.ts
  assertions.ts

Tokia struktūra atskiria testų scenarijus nuo techninių request detalių. Testai tampa trumpesni, o API client klasės gali būti naudojamos ir API, ir UI testų setup žingsniuose.

Dažniausios API testavimo su Playwright klaidos

• tikrinamas tik status kodas, bet ne response body arba verslo taisyklė;
• testai priklauso nuo rankiniu būdu paruoštų duomenų;
• token'ai ir slapti raktai laikomi kode;
• per daug techninės logikos rašoma tiesiai testuose;
• neigiami scenarijai visai netestuojami;
• API testai dubliuoja UI testus, bet nedengia papildomos rizikos;
• nėra aiškios strategijos, kurie API testai turi stabdyti release.

Kaip ir su UI automatizavimu, čia laimi ne testų kiekis, o jų stabilumas, aiškumas ir ryšys su realia produkto rizika.

API testai CI/CD procese

API testai puikiai tinka CI/CD, nes dažniausiai vyksta greičiau nei UI testai ir nereikalauja naršyklės. Jie gali būti pirmas automatinis kokybės filtras pull request arba merge metu.

Praktinė pipeline seka gali atrodyti taip:

1. unit testai;
2. API smoke testai;
3. platesni API regression testai;
4. UI smoke testai;
5. ilgesnis UI regression rinkinys pagal poreikį.

Tokia seka leidžia greičiau sustabdyti blogus pakeitimus. Jei API smoke testai krenta, dažnai neverta net pradėti ilgesnių UI scenarijų.

Plačiau apie pipeline organizavimą skaitykite: CI/CD testų integracija su Azure DevOps ir Playwright CI/CD pipeline.

Susiję straipsniai

• Kaip pradėti su Playwright
• Playwright lokatoriai
• Playwright Page Object Model
• Playwright CI/CD pipeline
• CI/CD testų integracija su Azure DevOps
• Unit, integration ir E2E testai
• Testavimo strategija startupams
• Testų automatizavimas
• Testavimo paslaugos

DUK apie API testavimą su Playwright

Ar Playwright tinka API testavimui?

Taip. Playwright turi integruotą API request kontekstą, leidžia siųsti HTTP užklausas, tikrinti atsakymus, naudoti autentikaciją ir derinti API testus su UI scenarijais viename projekte.

Kada verta rašyti API testus vietoje UI testų?

API testai dažniausiai verti tada, kai reikia greičiau ir stabiliau patikrinti verslo logiką, atsakymų struktūrą, roles, autorizaciją ar integracijas be naršyklės sluoksnio.

Ar Playwright API testus galima leisti CI/CD pipeline?

Taip. Playwright API testai gerai tinka CI/CD, nes yra greiti, lengvai paleidžiami pipeline aplinkoje ir gali būti naudojami kaip ankstyvas kokybės signalas prieš ilgesnius UI testus.

Kaip tvarkyti autentikaciją API testuose?

Dažniausiai autentikacija valdoma per request headers, bearer token, cookies arba specialų login žingsnį testų setup etape. Slapti raktai turi būti laikomi aplinkos kintamuosiuose arba CI/CD secret'uose, o ne testų faile.

Ar Playwright gali būti naudojamas ir UI, ir API testams viename projekte?

Taip. Tai vienas praktiškiausių Playwright privalumų: API ir UI testus galima laikyti tame pačiame projekte, naudoti bendrą konfigūraciją ir API sluoksniu pasiruošti duomenis UI scenarijams.

Reikia pagalbos su Playwright API testais?

Padedame komandoms susikurti praktišką Playwright testavimo struktūrą: nuo API ir UI testų balanso iki CI/CD integracijos, testinių duomenų valdymo, reportų ir stabilesnio release proceso.

Jei norite sumažinti lėtų UI testų kiekį, greičiau tikrinti kritinę backend logiką arba sujungti API testus su Playwright UI scenarijais, galime padėti pasirinkti aiškų starto planą.

Susisiekite dėl Playwright API testavimo →