E2E testiranje – pametna priprema za produkciju

Kako vremenom vaša aplikacija raste i dobija sve više funkcionalnosti, tako postaje sve teže da ispratite šta se zapravo dešava ispod haube. A činjenica je da se dešava mnogo toga: frontend šalje zahtev backendu, backend poziva bazu podataka, API komunicira sa eksternim servisima, dok korisnik vaše aplikacije sve vreme očekuje da sve to radi brzo i bez greške.

Ako ste ikada pustili novu verziju aplikacije i odmah posle deployment-a dobili poruku „ne radi login“, znate koliko stvari može da pođe po zlu iako su svi testovi prošli. 

Upravo zbog toga postoji End-to-End testiranje, poznato kao E2E testiranje. U pitanju je čitav niz unapred pripremljenih provera kako vaš sistem funkcioniše kao celina, od početka do kraja, upravo onako kako bi ga koristio korisnik u realnom svetu.

Na primer: zamislite da korisnik pokušava da se registruje na vašem sajtu, potvrdi mejl, prijavi se, doda proizvod u korpu, plati i dobije račun. Ako ijedan od tih koraka zakaže, korisnično iskustvo je nepovratno narušeno, čak i ako većina funkcionalnosti radi besprekorno. E2E test upravo služi tome da na vreme proveri da li svi ti delovi zajedno funkcionišu kako je previđeno.

Pre nego što nastavimo, da napomenemo da E2E po definiciji nije klasičan automatizovani test aplikacija. Ipak, automatizacija je jedan od bitnih segmenata koje je važno imati u vidu i kod ove vrste testova.

Ukoliko vas zanimaju neki od naprednih alata za automatizaciju testova, predlažemo da pročitate naš tekst Popularni alati za automatsko testiranje web aplikacija.

Šta znači testirati „od početka do kraja“

Za razliku od unit testiranja, koje proverava pojedinačne funkcije, ili integration testiranja, koje ispituje komunikaciju između modula, E2E test posmatra aplikaciju kao jednu živu celinu. Cilj je da proverite da li sve komponente: frontend, backend, baze, API-ji i eksterni servisi, međusobno sarađuju i daju očekivan rezultat korisniku.

Suština E2E testiranja nije samo da utvrdi da li kod radi, već da proveri kako se aplikacija ponaša u realnim uslovima. Na primer, ako korisnik ne može da dovrši registraciju jer se ne šalje verifikacioni mejl, problem možda nije u frontend logici, već u integraciji sa SMTP servisom. Klasičan unit test to verovatno neće primetiti, ali E2E test hoće.

Kao developeru, to vam daje uvid u to kako vaš kod radi u produkciji i kako sve komponente koje ste povezali funkcionišu u stvarnom scenariju.

Zašto je E2E testiranje važno

Kada vaša aplikacija dospe u produkciju, korisnici ne razmišljaju o tome koji API endpoint nije odgovorio ili koji SQL upit je spor. Njih zanima samo jedno: da li sve radi. E2E testiranje daje jasan odgovor na to pitanje mnogo pre nego što korisnici uopšte dođu do vašeg sajta ili aplikacije.

Dobro sprovedeno E2E testiranje pomaže da greške otkrijete ranije, pre nego što se pretvore u skupe probleme. Takođe, daje timu sigurnost da nove verzije aplikacije neće pokvariti nešto što je ranije radilo. Kada znate da je svaki ključni tok prošao proveru, možete bez bojazni da pustite update u produkciju.

Osim toga, E2E testovi mogu da otkriju i probleme sa performansama. Na primer, šta se dešava ako 50 korisnika u isto vreme pokuša da izvrši kupovinu? Da li sistem i dalje funkcioniše, ili dolazi do zastoja? Takvi testovi često otkrivaju uska grla koja se ne primete u klasičnim testovima.

E2E test vam pokazuje da li su vaši servisi dovoljno otpornI, da li API pozivi imaju očekivanu latenciju i da li se korisnički tokovi ponašaju predvidivo pod opterećenjem.

Kako izgleda proces E2E testiranja

Proces end-to-end testiranja ima više faza, a svaka od njih ima svoju svrhu. Hajde da ih prođemo redom.

1. Planiranje i definisanje scenarija

Prvi korak je razumevanje korisnika i njegovog toka kroz aplikaciju. Tester mora da zna kako se aplikacija koristi u praksi. Gde se klikće, kako se kupuje, kako se prijavljuje ili plaća. Na osnovu toga se kreiraju realni korisnički scenariji.

Ako ste developer, ovo je trenutak kada vredi razmišljati izvan koda. Postavite sebi pitanje: koji su kritični putevi u aplikaciji? Da li login, checkout ili API za slanje mejla mogu da sruše iskustvo ako zakažu? Ti tokovi se zatim pretvaraju u konkretne test slučajeve.

Scenariji ne treba da obuhvataju samo idealne situacije, već i one manje prijatne, kao što su pogrešni unosi, gubitak konekcije ili greške servera. Upravo u tim slučajevima se vidi koliko je sistem zapravo stabilan.

2. Priprema test okruženja

E2E testiranje mora da se izvršava u okruženju koje što više liči na produkciju. U praksi se za to koristi staging verzija aplikacije, sa istim podešavanjima i API ključevima, ali sa test podacima.

Test podaci treba da budu realistični. Ako svi korisnici u testu imaju isto ime i istu lozinku, test može da prođe bez greške, a da u stvarnosti ne bi radio. Zato se često koriste generisani, raznovrsni podaci koji bolje oponašaju realne uslove: različita imena, valute, tipovi naloga i slično.

Ovo je i trenutak da razmislite o automatizaciji setup-a. Infrastruktura kao kod (Infrastructure as Code) i kontejnerizacija (Docker, Docker Compose) mogu vam olakšati ponavljanje test okruženja i učiniti testove predvidivim i stabilnim.

3. Odabir alata

Zavisno od tipa aplikacije, biraju se i odgovarajući alati. Za web aplikacije to su najčešće Cypress, Selenium ili Playwright, dok se za mobilne koristi Appium.
Suština je da odaberete alat koji daje stabilne i lako održive testove, a ne nužno najmoderniji.

Evo jednog jednostavnog primera E2E testa napisanog u Cypressu, koji proverava proces prijave korisnika:

describe('Login test', () => {

  it('should successfully log in with valid credentials', () => {

    cy.visit('https://mojaaplikacija.rs/login');

    cy.get('input[name="email"]').type('korisnik@test.com');

    cy.get('input[name="password"]').type('test1234');

    cy.get('button[type="submit"]').click();

    cy.url().should('include', '/dashboard');

    cy.contains('Dobrodošli nazad').should('be.visible');

  });

});

Ovaj test simulira stvarno ponašanje korisnika: otvara login stranicu, unosi podatke, klikće na dugme i proverava da li je preusmeren na dashboard. Ako bilo koji od ovih koraka ne uspe, test pada.

Ako ste backend developer, vredi napomenuti da Cypress nije ograničen samo na UI. On može da testira i API tokove, što vam omogućava da proverite integraciju backend servisa bez manuelnih testova u Postmanu.

4. Kreiranje i izvršavanje testova

Kada su alati i scenariji spremni, kreću testovi. Oni simuliraju stvarne korisničke radnje, od logina do završetka kupovine. Tokom testiranja proverava se integritet podataka, ponašanje interfejsa i stabilnost sistema.

Ako se test ne automatizuje, može se sprovoditi i ručno, ali to zahteva više vremena i pažnje. Automatizacija ne znači da možete sve da prepustite robotu, već da testove možete ponavljati brže i doslednije. Dobar E2E test mora da bude fleksibilan i prilagodljiv promenama u korisničkom interfejsu ili logici aplikacije.

5. Analiza rezultata

Nakon izvršavanja testova, rezultati se upoređuju sa očekivanim ishodima. Cilj nije samo pronaći grešku, već i razumeti zašto se pojavila.

Da li problem nastaje pri validaciji podataka, pri komunikaciji između servisa, ili u bazi? Kvalitetna analiza često otkriva i obrasce. Recimo, da se greške javljaju samo pri većem opterećenju ili samo u određenim browserima.

Kao developer, treba da koristite ove rezultate da optimizujete delove aplikacije koji nisu očigledni: performanse baza, brzinu API odgovora, greške u logovima koje su se pojavile samo pod specifičnim uslovima.

6. Ispravke i ponovna verifikacija

Kada se problemi otkriju, programeri ih ispravljaju, a zatim se testovi ponovo pokreću da bi se proverilo da li je sve rešeno. Taj proces se obično ponavlja više puta. Važno je da se ništa ne podrazumeva. Činjenica da je test jednom prošao ne znači da će proći i sledeći put, posebno ako se menja backend logika.

U ovoj fazi dolazi do izražaja dobra dokumentacija testova. Ako jasno opisujete scenarije i očekivane rezultate, vaši testovi postaju alat koji ceo tim razume, a ne samo osoba koja ih je napisala.

7. Automatizacija i CI/CD integracija

Poslednji korak je povezivanje testova sa CI/CD procesom. To znači da se testovi automatski pokreću pri svakoj promeni koda, pre nego što se nova verzija aplikacije objavi. Ako neki test ne prođe, build se automatski zaustavlja, čime se sprečava da u produkciju ode verzija koja remeti postojeću funkcionalnost.

Na primer, pomoću GitHub Actions fajla testovi se mogu automatski pokretati ovako:

name: Run E2E Tests

on: [push]

jobs:

  e2e:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v3

      - name: Install dependencies

        run: npm install

      - name: Run Cypress tests

        run: npx cypress run

Ovakva integracija čini testiranje sastavnim delom vašeg razvojnog procesa, a ne nečim što se radi naknadno. Kada znate da se testovi pokreću automatski sa svakim push-om, možete biti mnogo sigurniji u stabilnost svog koda.

Zaključak

Kao što ste mogli da vidite, E2E testiranje je u neku ruku ogledalo vaše aplikacije. Ono otkriva i pokazuje ne samo da li sve funkcioniše, već i koliko je sistem stabilan, dosledan i spreman za stvarne korisnike.

Iako zahteva vreme i strpljenje, ovo testiranje je ulaganje koje se višestruko vraća. Donosi vam sigurnost, smanjuje rizike i obezbeđuje da vaš proizvod uvek radi onako kako korisnici očekuju.

Kada znate da je sve provereno od početka do kraja, onda možete dalje da deploy-ujete sa sigurnošću. Nema više neizvesnosti nakon push-a, i što je najvažnije nema iznenađenja u produkciji. Znate da ste sve pokrili, da sistem radi kao celina i da korisnik ima iskustvo koje ste vi kao programer želeli da isporučite: bez zastoja, bez iznenađenja, i sa potpunim poverenjem u ono što ste napravili.