Zašto se selen i krastavac ne smiju koristiti zajedno

U ovom postu objasnit ću zašto vjerujem da je loša ideja pisati UI automatizirane testove sa selenom i krastavcem.

U naslovu posta spominju se selenij i krastavac jer su najpopularniji alati za automatizaciju preglednika i BDD, međutim, kontekst ovog članka odnosi se na bilo koji alat za automatizaciju korisničkog sučelja u kombinaciji s bilo kojim BDD alatom.

Prije nego što dublje istražimo, pregledajmo neke osnovne informacije.

Što je selen?

Selen je alat za testiranje automatizacije preglednika koji je sposoban komunicirati s HTML elementima web aplikacije kako bi simulirao aktivnosti korisnika.

U programu Selenium WebDriver možemo pisati skripte na brojnim programskim jezicima i mogu biti velika prednost za višestruko testiranje OS-a i više pregledača.

Što je krastavac?

Krastavac stvoren je za pokretanje procesa razvoja usmjerenog na ponašanje (BDD), tako da kupac može svoje zahtjeve opisati kao niz primjera koji se nazivaju scenariji, u običnim tekstualnim datotekama korištenjem Gherkin jezika u formatu Give When Then.



U svijetu krastavaca ove se datoteke nazivaju datotekama značajki koje Scrum tim pregledava kako bi se jasno razumjelo zahtjeve prije početka stvarnog razvoja.

Jednom kad razvoj krene, programeri i / ili QA napisat će Definicije koraka koji su u osnovi isječci koda koji vežu scenarije iz datoteka značajki u testni kôd koji izvršava radnje protiv aplikacije koja se testira.

Selen i krastavac

I selen i krastavac sjajni su alati za svoje svrhe, ali kada se koriste zajedno, stvari se ne udaju lijepo! Da vidimo zašto.

Priče su obično napisane iz perspektive korisnika, na primjer:

Značajka: Funkcionalnost prijave

Kao korisnik web stranice abc.com

Želim da se kupci mogu prijaviti na web mjesto

Da bi mogli vidjeti podatke o svom računu.

Zauzvrat, scenariji u datotekama značajki napisani su na način koji opisuje ponašanje značajke kada korisnik komunicira s primjena . Na primjer:

Scenarij 1: Važeća prijava

S obzirom da sam na abc.com stranici za prijavu

Kad unesem valjane vjerodajnice

Tada sam preusmjeren na stranicu Moj račun

Tako možete dodati više scenarija za testiranje različitih kombinacija podataka.

Budući da su i priča i datoteka značajke napisane s gledišta visoke razine i budući da želimo automatizirati scenarije, čini se prirodnim početi pisati definicije koraka u Krastavcu koji pozivaju Selen za pokretanje aplikacije, izvršite radnje i provjeriti ishod.

Ali, tu se javlja problem; kad počnemo kombinirati selen s krastavcem za pisanje automatiziranih testova korisničkog sučelja.

Pošteno rečeno, u jednostavnim slučajevima kao što je gornji scenarij prijave, stvari se lijepo uklapaju i pristup se čini vjerojatnim, a zapravo se čini da se većina primjera koje vidite na internetu, demonstrirajući upotrebu selena i krastavca, ograničava na poznati primjer za prijavu.

Čitatelji takvih blogova pretpostavit će da mogu uzeti jednostavni scenarij prijave i primijeniti isti princip na širi kontekst aplikacije.

Ipak, nemojte se zavaravati, jer se sa selenom i krastavcem stvari mogu postati vrlo kisele kada se primijene na veliku stvarnu web-aplikaciju.

Uzmimo primjer stranice rezultata pretraživanja tipične aplikacije za e-trgovinu koja prodaje proizvode na mreži. Stranica rezultata pretraživanja obično je puna značajki, poput filtara, sortiranja, popisa proizvoda, mogućnosti promjene pretraživanja, mogućnosti paginiranja ili automatskog učitavanja pri pomicanju itd., Kao što se može vidjeti na snimci zaslona u nastavku:

Pretpostavit ću da je svaka značajka na stranici rezultata pretraživanja dodana na stranicu postupno pomoću agilnog razvoja.

Primjenjujući isti princip našeg jednostavnog primjera prijave, kako se razvija svaka značajka, imali bismo odgovarajuću datoteku značajki ispunjenu s puno različitih scenarija. Na primjer:

U iteraciji 1 razvoja razvija se 'Filtriranje prema cijeni', pa bismo za njega imali datoteku značajki sa svojim scenarijima vezanim uz filtar cijena.

U iteraciji 2 razvoja razvija se 'Filtriranje prema zvjezdanoj ocjeni', pa bismo za njega imali datoteku značajki sa svojim scenarijima povezanima s filtrom za ocjenu zvjezdica, i tako dalje za svaku novu značajku.

Važno je napomenuti da su scenariji u svakoj datoteci značajki specifični samo za njihovu značajku. Zapravo se zbog toga i zovu značajke datoteka jer je fokus na pojedinačne značajke .

Kao što je ranije spomenuto, kada je aplikacija jednostavna, možemo preživjeti izazov automatizacije scenarija na korisničkom sučelju pomoću selena i krastavca. Međutim, kako aplikacija raste i dodaju se nove značajke, pojavljuje se složenost jer mogu postojati ovisnosti između različitih značajki.

Na primjer, mogao sam prvo filtrirati rezultate pretraživanja prema cijeni, a zatim primijeniti drugi filtar za ocjenu zvjezdicama. Ah ... sada imamo problem!

Koju bi datoteku značajki sada trebao ići ovaj scenarij? U datoteci 'Filtriraj prema zvjezdici' ili 'Filtriraj prema cijeni'? Što kažete na to da sada dodam scenarij za primjenu sortiranja na svoje filtrirane rezultate za sortiranje po najvećem broju glasova?

Ako dionik želi vidjeti koja je naša pokrivenost testom, koju od datoteka značajki treba pogledati? Hoće li dobiti potpunu sliku pokrivenosti scenarija čitajući samo jednu od datoteka značajki ili će trebati pročitati sve datoteke značajki?

U vrijeme razvoja, kada se svaka značajka razvija pojedinačno u svakoj iteraciji, datoteke značajki bile bi usredotočene na samu značajku, pa u nekom trenutku, kada imamo više značajki, moramo početi razmišljati o njihovom testiranju, a ne samo izolirano, već i kreativni scenariji u kojima kombiniramo različite značajke.

I zapravo, to će učiniti stvarni korisnici aplikacije. Prvo će unijeti svoje kriterije pretraživanja, jednom na stranici rezultata pretraživanja, možda će paginirati, zatim filtrirati, zatim sortirati, vratiti se i tako dalje, a te radnje mogu raditi u bilo kojem redoslijedu. Neće biti propisani redoslijed događaja. Ovo je stvarno putovanje korisnika i pravi test sustava!

Većina programskih pogrešaka izložena je kada je značajka sama po sebi greška ili kada dvije značajke koje savršeno dobro rade izolirano ne rade zajedno. Na tome se temelji model ispitivanja u paru.

Pa, u čemu je velika stvar zajednička upotreba selena i krastavca?

Gdje god je to moguće, ne bismo trebali koristiti web GUI za funkcionalnu provjeru. Funkcionalnost značajke treba testirati na API sloju integracijskim testovima.

Korisničko sučelje trebalo bi biti rezervirano samo za provjeru korisničkih tijekova kroz aplikaciju ili testove od kraja do kraja i osiguravanje prisutnosti relevantnih očekivanih modula ili dodataka na stranici dok korisnik prelazi s jedne stranice na drugu.

Tipično putovanje korisnika podrazumijevalo bi:

1 - Idite na početnu stranicu web mjesta abc.com

2 - Potražite proizvod sa početne stranice

3 - Pregledajte popis rezultata pretraživanja

4 - Primijeni filtar i / ili sortiraj

5 - Pročitajte detalje o proizvodu

6 - Dodajte proizvod u košaricu

7 - Nastavite provjeravati ...

Selen je izvrstan u automatizaciji ovih scenarija i provjeri različitih elemenata na svakoj stranici, i kao što sam gore spomenuo, na to bismo se trebali usredotočiti prilikom testiranja na sloju korisničkog sučelja i testiranja prijelaza različitih stanja.

Kao što se može vidjeti, svako putovanje korisnika kroz aplikaciju dodiruje mnoge stranice i potencijalno komunicira s više značajki na svakoj stranici, a mi bismo provjeravali razne stvari u svakom koraku tijekom putovanja, pa bi pomoću datoteka značajke dokumentiranje ovih scenarija nema apsolutno nikakvog smisla, jer ne testiramo značajku, već testiramo integrirani sustav.

Stvari doista idu u obliku kruške kada pokušavamo napisati scenarije s kraja na kraj u formatu Dato-kada-onda. Koliko ćemo Givenova imati? Koliko ćemo Thena imati?

Moglo bi se tvrditi da bismo za end-to-end testove mogli samo koristiti Selenium samostalno bez Krastavca i imati zasebne automatizirane testove za svaku značajku pomoću selena i krastavca. Opet, ne preporučujem ovaj pristup jer ćete eventualno imati dvostruke testove i znamo koliko su spori i lomljivi testovi korisničkog sučelja, pa bismo trebali težiti da ih bude manje, a ne više! Štoviše, morat ćete se nositi s testovima ovisnosti o značajkama.

Sažetak

Krastavac je izvrstan alat za provjeru ponašanja značajke na API sloju s integracijskim testovima gdje se svaka značajka može temeljito testirati. Ovaj bi se alat trebao koristiti za testiranje priča.

Selenij je izvrstan alat za automatizaciju korisničkih scenarija na sloju korisničkog sučelja i provjeru ponašanja sustava u cjelini, obuhvaćajući mnoge korisničke priče.

Kada dođemo do testiranja integracije sustava ili testiranja korisničkog sučelja, najbolje je koristiti Selen bez temeljnog okvira Krastavca jer pokušaj pisanja datoteka značajki Krastavca za korisnička putovanja može biti vrlo glomazan i ne bi služio svrsi za koju je alat napravljen.

Moj se članak temelji na utvrđivanju činjenica!

  • Ako postoji vrijednost u korištenju krastavaca, to je na razini značajke.
  • Provjeru funkcionalnosti značajke najbolje je provoditi izvan korisničkog sučelja, npr. API testovi.
  • Čak i na testovima API sloja krastavac loše propada.
  • UI testovi trebali bi obuhvaćati korisničke / poslovne scenarije, a ne pojedinačne značajke.

Krastavac lijepo funkcionira s pojednostavljenim i naivnim pogledom na testove i scenarije, kao što je svima omiljena funkcionalnost prijave.

S obzirom da sam na stranici za prijavu
Kad unesem valjane vjerodajnice
Tada bih trebao vidjeti svoj račun

Ali bilo koji pametni tester zna da čak i jednostavna funkcionalnost prijave ima mnogo provjera. Pokušajte pretvoriti te čekove u krastavac.

Ovo je samo za prijavu; pokušajte napisati test od kraja do kraja na krastavcu!

UI testovi trebali bi obuhvaćati korisnička putovanja koja su obično od kraja do kraja i imaju više značajki aplikacije.

Puno se toga događa u jednom korisničkom putovanju kroz aplikaciju.

Krastavac definitivno NIJE pravi alat za testiranje korisničkog / poslovnog scenarija.