Millal tasub testimist automatiseerida? Selenium, Playwright ja Appium

„Kas peaksime testautomaatika üles seadma?“ on üks küsimusi, mida väikesed meeskonnad ja tooteomanikud kõige sagedamini esitavad. Vastus ei ole ei „kindlasti“ ega „ärge vaevuge“. Õigesse kohta paigutatuna säästab automatiseerimine iga väljalaske juures tunde; valesse kohta paigutatuna muutub see hooldamata testide hunnikuks, mis on alati punased ja mida keegi enam ei vaata. Selles artiklis selgitan praktiliselt, mida käsitsi- ja automaattestimine katavad, millal automatiseerimine end ära tasub, kuidas valida Seleniumi, Playwrighti ja Appiumi vahel ning kust alustada.

Mida katavad käsitsi- ja automaattestimine?

Käsitsitestimine tähendab, et inimene kasutab rakendust päriselt ja kontrollib seda. Inimsilm märkab veidraid disainidetaile, segadusttekitavaid tekste ja vooge, mis „töötavad, aga pole loogilised“. Uurivaks testimiseks, kasutatavuse hindamiseks ja uue funktsiooni esmaseks kontrolliks on käsitsitestimine asendamatu.

Automaattestimine tähendab, et kood käivitab eelnevalt määratud samme ikka ja jälle täpselt samamoodi. See ei väsi kunagi, ei jäta ühtegi sammu vahele ja suudab minutitega läbida kümneid stsenaariume. Kuid see kontrollib ainult seda, mida tal on kästud kontrollida: see ei „märka“ uusi vigu, vaid kontrollib, kas teadaolev käitumine endiselt töötab.

Lühidalt: need kaks ei ole konkurendid, vaid täiendavad teineteist. Automatiseerimine võtab üle korduvad kontrollid, et inimesed saaksid oma aega kasutada seal, kus on vaja päriselt mõelda.

Millal automatiseerimine end ära tasub?

Iga kirjutatud test on investeering: selle kirjutamine võtab aega ja ka selle uuendamine rakenduse muutudes võtab aega. Tavaliselt tasub see investeering end ära, kui:

• Testite sama voogu sageli. Kui klõpsite iga väljalaske eel käsitsi läbi sisselogimise, registreerumise, ostukorvi ja makse, on just need sammud esimesed automatiseerimise kandidaadid.
• Mõne voo katkiminek läheb kalliks. Ostukorv, mis ei võta makseid vastu, või katkine parooli lähtestamine tähendab kaotatud raha ja kaotatud kliente.
• Annate uusi versioone välja sageli. Meeskond, mis teeb väljalaskeid mitu korda nädalas, ei saa endale iga kord pikka käsitsi kontrollnimekirja lubada.
• Toetate mitut brauserit või seadet. Sama stsenaariumi käsitsi proovimine Chrome'is, Firefoxis ja Safaris muutub kiiresti tüütuks.
• Toode on küpseks saanud. Varajases prototüübis, mille liides muutub iga nädal, lähevad testid pidevalt katki; kui põhivood on paika loksunud, muutub automatiseerimine palju tõhusamaks.

Seevastu ühekordse kampaanialehe, väga varajase MVP või visuaalse disaini ülevaatuse puhul on käsitsitestimine tavaliselt mõistlikum valik.

Tööriista valik: Selenium, Playwright, Appium

Selenium

Selenium on kõige väljakujunenum brauseriautomaatika tööriist ja W3C WebDriver standardi alus. See toetab paljusid keeli, sealhulgas Java, Python, C#, JavaScript ja Ruby, ning Selenium Grid võimaldab käivitada teste paralleelselt mitmes masinas. Kui teie meeskond töötab juba Java või C# keskkonnas või teil on olemas ettevõtte testitaristu, on Selenium endiselt tugev valik. Puuduseks on see, et ootamisloogika ja aruandluse peate sageli ise ehitama.

Playwright

Playwright on Microsofti arendatud uuem tööriist. See juhib Chromiumi, Firefoxi ja WebKiti mootoreid ühe API kaudu ning toetab TypeScripti/JavaScripti, Pythonit, Javat ja .NET-i. Selle suurim eelis on automaatne ootamine: see ootab ise, kuni element on tõesti suhtluseks valmis, mis vähendab oluliselt ebastabiilseid teste. Sisseehitatud testikäivitaja, paralleelne käivitamine, ekraanipildid, videod ja sammhaaval uurimist võimaldav trace viewer on kohe kaasas. Nullist alustava veebiprojekti puhul soovitan tavaliselt just Playwrighti.

Appium

Kui teil on veebisaidi asemel natiivne Android- või iOS-rakendus, tuleb mängu Appium. Ka Appium kasutab WebDriver protokolli ning käivitab teste päris seadmetes ja emulaatorites selliste draiverite kaudu nagu UiAutomator2 Androidi ja XCUITest iOS-i jaoks. Seadistamine on keerukam kui veebitööriistadega ning mobiilitestid on oma olemuselt aeglasemad, seega tasub mobiilis stsenaariumide arvu osas olla eriti valiv.

Väike Playwrighti näide

Allolev test kontrollib, et kasutaja saab sisse logida ja näeb töölauda. Päris projektides on esimesed testid, mille kirjutan, tavaliselt sama lihtsad:

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test('user can log in and see the dashboard', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill('demo@example.com');
  await page.getByLabel('Password').fill('correct-password');
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Playwright waits automatically until these become true (or times out)
  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

// Run: npx playwright test

Pange tähele, et CSS-klasside asemel kasutatakse selektoreid, mis põhinevad sellel, mida kasutaja näeb, näiteks getByRole ja getByLabel. Nii lähevad testid disaini muutumisel harvemini katki.

CI integratsioon

Testid näitavad oma tegelikku väärtust siis, kui need käivituvad automaatselt, ilma et keegi peaks neid meeles pidama. Lisate CI-süsteemi, näiteks GitHub Actionsi või GitLab CI, sammu, mis käivitab testid iga pull requesti või põhiharusse tehtava pushi korral; kui mõni test ebaõnnestub, blokeeritakse ühendamine ning aruanne, ekraanipildid või trace-failid säilitatakse artefaktidena. Playwright pakub selleks valmis CI-juhendit ja näidiskonfiguratsioone ning enamikus projektides võtab esmane seadistus vähem kui tunni.

Levinud vead

• Püüd testida kõike. Sajad otsast lõpuni testid annavad aeglase ja raskesti hooldatava testikomplekti. Tervislikum on katta kriitilised vood otsast lõpuni ning detailid ühiku- ja API-testidega.
• Ebastabiilsete testide eiramine. Test, mis vahel läbib ja vahel mitte, hävitab meeskonna usalduse testitulemuste vastu. Kasutage fikseeritud sleep-kutsete asemel tingimuspõhiseid ootamisi ning parandage ebastabiilne test kohe või lülitage see ajutiselt välja ja pange kirja.
• Haprad selektorid. Pikad XPathid või automaatselt genereeritud CSS-klassid lähevad katki väikseimagi disainimuudatuse peale. Eelistage ligipääsetavaid rolle, silte või spetsiaalseid data-testid atribuute.
• Teineteisest sõltuvad testid. Iga test peaks ise oma andmed ette valmistama ja suutma iseseisvalt käivituda; vastasel juhul kukub järjekorra muutumisel kõik kokku.
• Hoolduskulude eiramine. Testikood on samuti kood: see peab jääma loetavaks ja seda tuleb rakenduse muutudes uuendada.

Kuidas alustada

1. Pange kirja kolm kuni viis kriitilist voogu, mille rikkiminek läheks teile kõige kallimaks: tavaliselt sisselogimine, registreerumine, makse ja põhifunktsioon.
2. Kirjeldage need vood esmalt lihttekstina samm-sammult; sellest saab ühtlasi teie käsitsitestimise kontrollnimekiri.
3. Automatiseerige need stsenaariumid veebi puhul Playwrighti või mobiili puhul Appiumiga.
4. Ühendage testid CI-ga ja käivitage need iga muudatuse korral.
5. Laiendage testikomplekti järk-järgult, kui leitakse päris vigu või lisandub uusi kriitilisi funktsioone.

Väike, kuid usaldusväärne testikomplekt on alati väärtuslikum kui suur, mida keegi ei usalda.

Kokkuvõte

Testautomaatika ei ole eesmärk omaette, vaid tööriist, mis võimaldab uusi versioone rahuliku südamega välja anda. Õigete voogude ja õige tööriistaga tasub see end kiiresti ära ka väikestes meeskondades. Kui soovite koos välja selgitada, milliseid stsenaariume teie projektis tasub automatiseerida, või muuta olemasolevaid teste usaldusväärsemaks, võtke julgelt ühendust.