Geb în practică
Sunt aici, să zicem, îmi place când toată munca pentru mine este făcută de roboți. Prin urmare, consider că este necesar să se utilizeze scripturi, inspecții, verificări de ortografie și, desigur, teste automate. Apropo, cum vă place acest test:
Mi se pare că astfel de teste au un grad înalt de lizibilitate - nici măcar nu contează ce limbă este. Puteți scrie mai multe teste similare pe acest model, fără nici o idee despre Geb, Groovy și cum funcționează. Dar pentru o înțelegere completă, să aruncăm o privire profundă la elementele de bază.
Despre Geb și Seleniu
Cine în zilele noastre nu a auzit de Seleniu. Probabil, cineva care încă nu a mirosit praful și tot crede că toate browserele sunt la fel. Pentru mult timp nu voi vorbi despre asta, știu doar:
- Selenium vă permite să executați teste automate chiar în browser-ul dvs., reproducând tot felul de probleme și trăsături.
- Puteți face tot ceea ce face un utilizator normal, și anume, tastați text, derulați, mutați mouse-ul etc. Monitorizând cu atenție comportamentul paginii din browser.
De fapt, Selenium este un robot deplin pentru testarea în condiții cât mai apropiate de realitate. (Din punct de vedere istoric, vă puteți aminti și Robotul Rational, care a fost închis în Internet Explorer și a avut oportunități destul de slabe pentru a interacționa cu pagina.)
Seleniul în sine oferă câteva opțiuni pentru scrierea testelor:
Deci, Geb este un alt instrument de testare care utilizează WebDriver și se bazează pe limba Groovy. Puteți folosi Geb în interiorul scriptului Groovy folosind următoarele cuvinte magice:
Una dintre trăsăturile lui Groovy (precum și a tuturor limbilor dinamice) este că poate fi ușor readusă într-un alt limbaj complet nerecunoscut - pentru orice nevoie.
În cazul nostru, Geb oferă un limbaj de control al browserului. Puteți face tot ce poate face un utilizator uman:
- Navigați la adresa URL
- Completați formularele
- Mutați mouse-ul
- Faceți clic pe link
- Interacționează cu toate tipurile de ferestre și cadre pop-up.
După cum puteți vedea, Geb vă permite să utilizați o sintaxă care seamănă cu jQuery (dar nu coincide cu ea complet). Acest lucru este util pentru găsirea elementelor potrivite în pagină. Metoda click () permite să faceți clic pe elemente DOM, operație <<— отправлять браузеру текст, и так далее.
Pagini și module
și a trecut la gramant.com. Acum puteți citi această pagină. să analizeze și să găsească erori. Deci? De fapt, nu. Când un browser atinge o pagină, se poate întâmpla:
Credem că suntem pe aceeași pagină, dar pe de altă parte. Apoi, testele vor merge în mod greșit. Prin urmare, este foarte important să înțelegem pe ce pagină logică suntem.
Geb sugerează utilizarea paginilor logice (Page) și a așa-numitelor module (Module). Să încercăm să ilustrăm acest lucru cu următorul exemplu:
De ce avem nevoie de o astfel de abstracție ca o pagină. Se pare că te uiți la adresa URL actuală și vom afla. De exemplu, aceasta:
Dar se întâmplă că aceeași pagină logică poate avea mai multe adrese URL și stări diferite și nu este întotdeauna corect să definiți o pagină prin URL (care se poate schimba în mod imprevizibil). Puteți face acest lucru, de exemplu, după titlu:
Există și alte opțiuni pentru determinarea paginii curente; După cum puteți vedea, totul depinde foarte mult de aplicație. Uneori, multe adrese URL se potrivesc aceleiași pagini; uneori una și aceeași adresă URL, în funcție de contextul intern, poate să apară mai multe pagini diferite. În general, proprietatea pseudo-at conține logica pentru a determina dacă browserul este în prezent pe această pagină.
Câteva cuvinte despre module. Diagrama arată că modulul face parte din pagină (bloc) și există module care sunt prezente pe mai multe pagini. De exemplu, șirul de căutare Yandex este disponibil atât pe pagina de portal, cât și deasupra rezultatelor căutării. Semnificația modulelor este reutilizarea codului de testare.
Modulele pot fi definite, de exemplu, astfel:
Și apoi folosiți-le astfel:
Există, desigur, capacitatea de a defini multe instanțe ale modulului în interiorul paginii - aceasta este relevantă pentru diferite tipuri de liste. De exemplu, rezultatele căutării - fiecare rezultat poate fi declarat ca un modul. Acest lucru se face folosind constructul moduleList. pe care nu o voi opri.
AJAX și totul, totul, totul
În vremurile moderne, multe lucruri minunate se pot întâmpla în interiorul browserului:
- Solicitări AJAX
- animație
- trage picătură
- Ferestre popup de diferite tipuri
Testarea unor astfel de piese este posibilă în mod automat numai cu ajutorul testelor în browser. Geb oferă mai multe instrumente:
De asemenea, puteți utiliza funcții globale:
Pentru a emula evenimentele mouse-ului, este convenabil să folosiți jQuery. Geb oferă o proprietate jQuery specială pentru astfel de apeluri:
Această linie va funcționa numai dacă jQuery versiunea 1.4 și versiunea superioară este încărcată pe pagina testată. De fapt, acest cod este tradus în js.exec ().
Starea de așteptare
Acest script primește un cod încorporat pentru videoclipul YouTube, apăsând câteva butoane și așteptând terminarea animației.
Desigur, metoda de așteptare pentru totdeauna nu va aștepta și după ce va ajunge la un anumit timp de expirare se va prăbuși, întrerupând testul. Valoarea implicită este de 5 secunde.
Utilizarea WebElement și acțiunile
Am menționat despre Drag Picătură. În prezent (versiunea 0.6.2), Geb nu are o abstracție convenabilă pentru astfel de operațiuni. Cu toate acestea, puteți utiliza direct seleniul direct accesând o instanță WebDriver (prin browser.driver):
Geb în Grails
Pentru a utiliza Geb în Grails, este convenabil să utilizați plug-in-ul Spock. Nu voi petrece mult timp pe Spock Framework, există suficiente informații despre asta. Spock este mai convenabil decât standardul JUnit, în primul rând pentru că vă permite să scrieți teste în specificațiile dumneavoastră meta-lingvistice (din nou bazate pe Groovy). Aceasta se dovedește a fi mai scurtă și mai expresivă.
Câteva cuvinte despre configurarea lui Geb for Grails 1.3.x. Un exemplu de astfel de proiect este postat aici. Secțiunea necesară din BuildConfig.groovy va arăta astfel:
GebVersiunea curentă este 0.6.2, înlocuiește-o.
Știm că există două tipuri de teste în Grails - test / unitate și test / integrare. Spock adaugă și mai multe teste / teste funcționale - "funcționale".
Geb în cadrul testelor funcționale (specificațiile Spock) este similar cu cel obișnuit, dar nu este necesar să porniți browserul și să configurați driverul în cadrul testului - totul sa făcut deja. Un exemplu de specificație simplă (presupunem că clasele HomePage, LoginPage pe care le-am descris deja):
Desigur, există și fișiere de configurare Geb care definesc:
- Ce browser să utilizeze și ce driver
- Diverse setări Geb (cum ar fi timpul de expirare).
În demo există un exemplu de fișier GebConfig.groovy.
Se pare că este suficient. Introducem:
și vezi cum robotul nostru încearcă să testeze ceva acolo.
Se pare rapid că în Chrome și IE testele noastre nu funcționează. Motivul este că este cu adevărat posibil să rulați fie HtmlUnit (care este inutil pentru teste), fie din Firefox. Pentru Firefox, este creat automat un nou profil, care "extinde" browser-ul pentru gestionarea ulterioară prin FirefoxDriver. Da, Selenium / Geb funcționează excelent pe Firefox, deoarece pentru Firefox a fost inițial dezvoltată.
În ceea ce privește IE și Chrome, atunci cu ei totul este ceva mai complicat. Situația generală poate fi înțeleasă din tabel:
Versiuni 6,7,8,9. Sprijină exact o instanță a browserului.
După cum vedeți, driverul Chrome nu acceptă acțiuni! Ceea ce este destul de neplăcut.
Ce altceva sprijină oficial seleniul (și, prin urmare, Geb)?
- IPhone Browser
- Browserul Android
Ar trebui să scriu teste de browser?
Farmecul testelor de browser în comportamentul garantat pe un anumit browser.
Cu toate acestea, testele browserului:
Formula cea mai simplă care descrie necesitatea de a scrie teste automate poate să arate astfel:
Formula este frumoasă, dar mai degrabă lipsită de sens, deoarece este foarte dificil să estimăm în avans complexitatea suportului și costul testelor iterative manuale. Dar este clar că, odată cu creșterea numărului de iterații, gândurile de automatizare a testelor vor veni în minte din ce în ce mai des. La o turație redusă a testelor de browser, nu poți acorda prea multă atenție - este încă mai rapid decât efectuarea testelor manuale. Adevărat, formula nu ia în considerare faptul că nu toate lucrările manuale pot fi automatizate - încercați, să spunem, explicați robotului ce înseamnă "a face planul să meargă".
Există și câteva subtilități în testarea browserului. De exemplu, Selenium nu este întotdeauna în măsură să determine pe cont propriu dacă site-ul pe care browserul a vizitat-o este disponibil deloc. Într-adevăr, în cazul, să spunem, tăierea Internetului, browserul pare să arate ceva. Dar aceasta nu este pagina dvs. de așteptat, ci un mesaj de browser intern în stilul "Verificați setările dvs. de Internet". Toate aceste situații trebuie să le definiți și să le includeți în pachetul de testare. În plus, uneori trebuie să adaptați aplicația pentru teste automate, urmărind unele compromisuri.
În general, acest lucru poate părea neobișnuit, dar un test automat este un program. Prin urmare, uneori dezvoltarea și susținerea acestuia pot fi atribuite programatorilor. Această abordare elimină împărțirea strictă a muncii între programator și tester. În cadrul unui sistem stabilit de asamblare și testare, unii dintre aceștia aplică principiul "el a rupt el însuși testul, el și restul". Aceasta este, în general, nu contează cine a scris testul - de la înființarea sa a devenit o proprietate comună, iar responsabilitatea pentru test este suportată de testere și de programatori.
Articole similare
Trimiteți-le prietenilor: