Aplicațiile de revizuire sunt grozave: pentru fiecare cerere de îmbinare (sau sucursală, de altfel), noul cod poate fi copiat și implementat într-un mediu live proaspăt de tipul producției, reducând efortul de evaluare a impactului modificărilor. Astfel, atunci când folosim un manager de dependență precum Dependencies.io, acesta poate trimite o cerere de îmbinare cu o dependență actualizată și va fi imediat clar că aplicația poate fi încă construită și implementată corect. La urma urmei, îl puteți vedea rulând!

webdriverio

Cu toate acestea, examinarea codului proaspăt implementat pentru a verifica dacă arată și se comportă așa cum era de așteptat este o muncă manuală repetitivă, ceea ce înseamnă că este un candidat principal pentru automatizare. Aici intervine testarea automată end-to-end: computerul rulează prin câteva scenarii simple care necesită funcționarea corectă a tuturor straturilor aplicației dvs., de la frontend la baza de date.

În acest articol, vom discuta despre cum să scrieți astfel de teste end-to-end și despre cum să configurați GitLab CI/CD pentru a rula automat aceste teste împotriva noului dvs. cod, sucursal cu sucursală. Pentru scopul acestui articol, vă vom prezenta prin procesul de configurare a GitLab CI/CD pentru testarea cap la cap a aplicațiilor bazate pe JavaScript cu WebdriverIO, dar strategia generală ar trebui să fie transferată în alte limbi. Presupunem că sunteți familiarizați cu GitLab, GitLab CI/CD, Revizuirea aplicațiilor și rularea aplicației dvs. local, de exemplu, pe localhost: 8000 .

Ce să testez

În strategia de testare a piramidei utilizată pe scară largă, testele end-to-end acționează mai degrabă ca o măsură de protecție: cea mai mare parte a codului dvs. ar trebui să fie acoperită de teste unitare care vă permit să identificați cu ușurință sursa unei probleme, în cazul în care apare. Mai degrabă, veți dori, probabil, să limitați numărul de teste end-to-end la suficient de mult pentru a vă oferi încrederea că implementarea a mers conform intenției, că infrastructura dvs. funcționează și că unitățile de coduri funcționează bine împreună.

Seleniu și WebdriverIO

Selenium este un software care poate controla browserele web, de exemplu, pentru a le face să viziteze o anumită adresă URL sau să interacționeze cu elementele de pe pagină. Poate fi controlat programatic dintr-o varietate de limbaje de programare. În acest articol, vom folosi legările JavaScript WebdriverIO, dar conceptul general ar trebui să treacă destul de bine către alte limbaje de programare acceptate de Selenium.

Testele de scriere

Funcțiile îl descriu, îl și browserul sunt furnizate de WebdriverIO. Să le descompunem una câte una.

Funcția descrisă vă permite să grupați testele aferente. Acest lucru poate fi util dacă, de exemplu, doriți să rulați aceleași comenzi de inițializare (folosind beforeEach) pentru mai multe teste, cum ar fi asigurarea faptului că sunteți conectat.

Funcția pe care o definește un test individual.

Obiectul browserului este sosul special al WebdriverIO. Oferă majoritatea metodelor API WebdriverIO, care sunt cheia pentru conducerea browserului. În acest caz, putem folosi browser.url pentru a vizita/pagina-care-nu-există pentru a accesa pagina noastră 404. Putem apoi folosi browser.getUrl pentru a verifica dacă pagina curentă se află într-adevăr în locația specificată de noi. Pentru a interacționa cu pagina, putem trece pur și simplu selectoarele CSS către browser.element pentru a obține acces la elementele de pe pagină și pentru a interacționa cu ele - de exemplu, pentru a face clic pe linkul dinapoi la pagina de pornire.

Testul simplu prezentat mai sus ne poate da deja multă încredere dacă trece: știm că implementarea noastră a reușit, că elementele sunt vizibile pe pagină și că browserele reale pot interacționa cu ea și că rutare funcționează așa cum era de așteptat. Și toate acestea în doar 10 rânduri cu spații albe gratuite! Adăugați la testele unitare succesive și o conductă finalizată cu succes și puteți fi destul de încrezători că actualizarea dependenței nu a spart nimic fără a fi nevoie să vă uitați la site-ul dvs.

Alergând local

Vom trece într-o clipă la testul de mai sus în CI/CD. Cu toate acestea, atunci când scrieți teste, vă ajută dacă nu trebuie să așteptați ca conductele dvs. să aibă succes pentru a determina dacă fac ceea ce vă așteptați să facă. Cu alte cuvinte, să-l facem să ruleze local.

Asigurați-vă că aplicația dvs. rulează local. Dacă utilizați Webpack, puteți utiliza pluginul WebdriverIO Webpack Dev Server care pornește automat un server de dezvoltare înainte de a executa testele.

Documentația WebdriverIO are o prezentare generală a tuturor opțiunilor de configurare, dar cel mai simplu mod de a începe este să începeți cu configurația implicită a WebdriverIO, care oferă o prezentare generală a tuturor opțiunilor disponibile. Cele două opțiuni care vor fi cele mai relevante acum sunt opțiunea specs, care este o serie de căi către testele dvs. și opțiunea baseUrl, care indică locul în care rulează aplicația dvs. Și, în cele din urmă, va trebui să îi spunem WebdriverIO în ce browsere am dori să rulăm testele noastre. Acest lucru poate fi configurat prin opțiunea de capabilități, care este o serie de nume de browser (de exemplu, Firefox sau Chrome). Se recomandă instalarea selenium-assistant pentru a detecta toate browserele instalate:

Dar, desigur, ar funcționa și o simplă configurație a config.capabilities = ['firefox'].

Dacă ați instalat WebdriverIO ca dependență (npm install --save-dev webdriverio), puteți adăuga o linie la proprietatea scripturilor din package.json care rulează wdio cu calea către fișierul de configurare ca valoare, de exemplu:

Apoi puteți executa testele folosind npm run-check-check, după care veți vedea de fapt o nouă fereastră de browser care interacționează cu aplicația dvs. așa cum ați specificat.

Configurarea GitLab CI/CD

Ceea ce ne aduce la partea interesantă: cum rulăm acest lucru în GitLab CI/CD? Există două lucruri pe care trebuie să le facem în acest sens:

  1. Configurați lucrări CI/CD care au de fapt un browser disponibil.
  2. Actualizați configurația noastră WebdriverIO pentru a utiliza aceste browsere pentru a vizita aplicațiile de revizuire.

Pentru domeniul de aplicare al acestui articol, am definit o verificare de încredere suplimentară a etapei CI/CD care se execută după etapa care implementează aplicația de revizuire. Folosește nodul: cea mai recentă imagine Docker. Cu toate acestea, WebdriverIO declanșează browsere reale pentru a interacționa cu aplicația dvs., deci trebuie să le instalăm și să le rulăm. În plus, WebdriverIO folosește Selenium ca o interfață comună pentru a controla diferite browsere, deci trebuie să instalăm și să rulăm și Selenium. Din fericire, proiectul Selenium oferă imaginilor Docker standalone-firefox și standalone-chrome care oferă exact asta pentru Firefox și, respectiv, Chrome. (Deoarece Safari și Internet Explorer/Edge nu sunt open source și nu sunt disponibile pentru Linux, din păcate nu putem să le folosim pe cele din GitLab CI/CD).

GitLab CI/CD face foarte ușoară conectarea acestor imagini la joburile noastre de verificare a încrederii folosind proprietatea serviciului, ceea ce face ca serverul Selenium să fie disponibil sub un nume de gazdă bazat pe numele imaginii. Configurația noastră de locuri de muncă arată astfel:

Și la fel pentru Chrome:

Acum că avem o treabă pentru a rula testele end-to-end, trebuie să îi spunem WebdriverIO cum să se conecteze la serverele Selenium care rulează alături de acesta. Am înșelat deja un pic mai sus, trecând valoarea opțiunii gazdă ca argument pentru a rula npm verificarea încrederii pe linia de comandă. Cu toate acestea, trebuie totuși să îi spunem WebdriverIO ce browser este disponibil pentru a-l utiliza.

GitLab CI/CD pune la dispoziție un număr de variabile cu informații despre jobul curent CI. Putem folosi aceste informații pentru a configura în mod dinamic configurația WebdriverIO în funcție de jobul care rulează. Mai exact, putem spune WebdriverIO pe ce browser trebuie să execute testul, în funcție de numele lucrării care rulează în prezent. O putem face în fișierul de configurare al WebdriverIO, pe care l-am denumit mai sus wdio.conf.js:

La fel, putem spune WebdriverIO unde rulează aplicația de examinare - în cazul acestui exemplu, este activată
.flockademic.com:

Și ne putem asigura că configurația noastră specifică locală este utilizată numai atunci când nu rulează în CI folosind if (! Process.env.CI). Acesta este practic toate ingredientele de care aveți nevoie pentru a rula testele end-to-end pe GitLab CI/CD!

Pentru a recapitula, fișierul nostru de configurare .gitlab-ci.yml arată cam așa:

Ce urmeaza

Dacă vă configurați acest lucru și doriți să aruncați o privire la configurația de lucru a unui proiect de producție, consultați:

  • Wdio.conf.js de Flockademic
  • Flockademic’s .gitlab-ci.yml
  • Testele Flockademic

WebdriverIO poate face multe mai multe. De exemplu, puteți configura un screenshotPath pentru a spune WebdriverIO să facă o captură de ecran atunci când testele eșuează. Apoi spuneți GitLab CI/CD să stocheze acele artefacte și veți putea vedea ce nu a funcționat în GitLab.