Inițializarea șoferului de unde să facă și de ce

Buna ziua tuturor,
Vreau să înțeleg teoria pentru mine. Unde este cel mai bun și în ce cazuri să inițializați șoferul?
Am întâlnit mai multe opțiuni:
- în testul însuși și îl transmiteți designatorului în pagină






- în testul însuși, dar înainte de a efectua testul, de exemplu, adnotarea în testng
- în pagina în sine (și atunci când pagina merge la pagina ridică conducătorul auto)

Poate că există câteva opțiuni interesante?

Îmi place ideea de a izola complet logica testelor de la șofer, dar bănuiesc că această metodă poate avea unele dezavantaje.

Nici una dintre opțiunile de mai sus nu este corectă. Ce descrieți este un modul specific domeniului.

Aceasta pare a fi și eticheta are dreptate, iar gândurile despre izolare sunt adevărate, dar, în opinia mea, trebuie mai întâi să dați seama ce este - cadrul. și de asemenea - de ce testele și paginile nu au nimic de-a face cu acest concept. Și apoi puteți vorbi despre locul în care WebDriver-ul însuși ar trebui izolat.

Despre cadrul este acceptat. De fapt, am înființat o astfel de etichetă deoarece era cea mai apropiată de întrebare (cea mai apropiată este de a înțelege este că alții nu erau deloc relevanți

Inițializarea șoferului de unde să facă și de ce
).

Sunt de acord cu afirmația că testele și paginile nu fac parte din cadrul.

Adevărat, cadrul. Acum, să încercăm să înțelegem de ce ar trebui să fie cadrul, pentru a asigura viteza și comoditatea menționate în dezvoltare, precum și - fiabilitatea testelor dvs., indiferent de AUT?

Metoda Socratic este serioasă

Inițializarea șoferului de unde să facă și de ce

Aceasta este ceea ce nu înțeleg, totuși ne confruntăm cu testele noastre din partea conducătorului auto (chiar dacă le luați pe toate la clasa de bază).

Vă mulțumesc pentru atenția acordată.

Și nu căutați exemple care să contrazică propriile dvs. concluzii.

Inițializarea șoferului de unde să facă și de ce
Sunteți atașat la o implementare specifică, care ar putea fi scrisă pe genunchi numai în scopuri educaționale.

Să presupunem că aveți un mecanic de conducere. care este situat în interiorul cadrului.
Se ridică o serie de întrebări:

  • În ce condiții trebuie inițializat / închis driverul?
  • Testele au într-adevăr nevoie de un șofer în cadrul nivelului de abstractizare considerat?
  • Ce module ale cadrului de fapt au nevoie de un conducător auto?
  • Cum se stabilește o conexiune flexibilă între modulele care au nevoie de un driver?

dacă doriți să furiți și să petreceți minim o jumătate de an pe scrierea unui ambalaj stabil peste seleniu și utilitare pentru proiector cu autotesturi. Apoi, ar trebui să aveți cu siguranță clase precum: BrowserFactory - cu un set de browsere, proprietăți pentru ele, alte acțiuni pe browsere; WebDriverHolder - cu instanța browserului; WebDriverInstances - care va seter browser-ul, vebdrayvera hetero și o astfel de „InheritableThreadLocal“ pentru a putea răni testele multithread.

Și dacă un astfel de timp pentru „svobododumiya“ (deși kostyleklepaniya general), o mai bună utilizare a soluțiilor gata făcute Seleniură, JDI (EPAM), alte preparate freyvorki (ambalaje de seleniu) sau în Python mondială RobotFramework
deși în Python nu știm ce este mai bine să îl folosiți, Pythonist vă poate spune cadre convenționale gata făcute

Pentru a începe, vă răspundeți la întrebări despre conceptul aplicației dvs. de testare în general, despre modul în care o veți construi și despre ce canoane. Poate chiar acum zakritikuyut, dar frumusețea și armonia autotest a codului, precum și viteza acestuia (exagerat, ca majoritatea dintre noi nu sunt în codul, dar în căutarea de elemente pe pagină) au o pondere mică. Testele ar trebui sprijinite în primul rând. Da, codul ar trebui să fie, de asemenea, OK, au proprietăți structurale care nu Paterna (pagina yelement), ce ai face nu scufundat, astfel încât codul nu ar trebui să fie complicat, dar simplu și nu grele și ușoare (Alexander Soloviov, salut pentru tine)
Acum despre sofer.
1. Dacă nu urmați unele sau Paterno, ideomam și experiența utilizării abordării DSL, puteți trece ca un șofer, oriunde, ai grija fata - multi au inceput, iar apoi ei înșiși prostia ozonavali. Experiența proprie este, de asemenea, necesară.
2. Dacă înțelegeți că lansarea driverului este o componentă configurabilă în cadrul infrastructurii, puteți descrie în mod clar unitatea pentru clasa de bază a paginilor / elementelor. Cu toate acestea, va trebui să completați clasele cu o funcționalitate de bază serioasă pentru a lucra cu elemente, nu este întotdeauna convenabilă, dar vă uitați și vedeți cât de transparent este DSL-ul.
3. Dacă urmați strategia compoziției cererii dumneavoastră, conducătorul auto va trece ca argument al clasei principală a aplicației, precum și pentru încercările expune metodele publice și atributele care sunt transferate la cererea ca un dispozitiv pentru test de coajă, care va exista până la sfârșitul testului - prindere sesiune.

în continuare IMHO: Cred că toată lumea ar trebui să aleagă orice abordare convenabilă pentru ei înșiși, deoarece testele de scris sunt pentru el, și de sprijin, de asemenea. Dacă dezvoltarea este efectuată de echipă, atunci această întrebare trebuie rezolvată și cu ei. În ambele cazuri, de asemenea, trebuie să înțeleagă că mai devreme sau mai târziu „caramida cade“, iar lucrarea se termină, și după ce altcineva totul va sprijini, așa că face același lucru într-un mod care ar avea urechile nu va arde.






În ceea ce privește programele foarte inteligente și codarea Zen, cred că testele ar trebui să fie scrise mai degrabă decât să fie exprimate în mod complex folosind instrumentele de limbaj de programare.

Interesant temka lichidate

Inițializarea șoferului de unde să facă și de ce
Da un exemplu, cineva poate veni la îndemână, sau ceva sensibil spune-mi ..

Pe telefonul mobil (Appium), am implementat un pic strâmb la aplicația ApplicationManager:

În timp ce experimentăm cu trezirea și probabil că merităm să schimbăm variabilele ENUM și să scăpăm de această încărcareConfigProp

ApplicationManager - aici la mine ecrane sunt inițializate, de asemenea, conducătorul auto cu.

De fapt, aici este ecranul:

Iată testul meu:

Desigur, Tetts tăiat, acolo am mai multe containere, în care logica este înțeleasă pentru diferite dispozitive și diferite nume și mesaje diferite, dar pentru un exemplu va fi clar ..

Am început să scriu totul când nu nicherta înțeleg, și a fost doar începutul pentru a înțelege de automatizare, astfel încât nu foarte bine aici toate sa întâmplat, iar acum re-scriere, astfel încât toate așteptările și metodele de componente UI - mutat pentru a separa clase.

Acesta este modul în care am un mobil pentru Android, cadrul este astfel, acum am înțeles deja ce este în neregulă, am o mică experiență, rescrie-o. Pe Web, totul va fi mai dificil, acolo am multithreading și o grămadă de browsere și rulează sub diferite sisteme de operare.

Când scriu un cadru în automatizare pentru mine, am evidențiat următoarele lucruri:

  1. întregul cod trebuie să fie reutilizat astfel încât paginile să aibă numai elemente și să lucreze cu ele
  2. la citirea testelor totul ar trebui să fie extrem de clar ce se întâmplă
  3. șoferul și așteptările nu ar trebui să fie în teste și nu ar trebui să fie în pagină
  4. toate metodele referitoare la elemente ar trebui să fie în clasa lor
  5. toate metodele privind așteptările - ar trebui să fie în clasa sa
  6. Cadrul trebuie să fie scris astfel încât să fi creat pentru prima dată testul, iar din acesta am generat deja metodele. Este mai ușor să vii cu un test, ce ar trebui să fie și apoi să scrieți metode pentru test
  7. toate nivelurile de acces trebuie respectate

Și eu inițializez conducătorul auto în clasa TestBase, din care toate martorile sunt moștenite, iar inițializarea are loc când începe testul)

O persoană trebuie să înțeleagă conceptul pentru a începe. Și îi dai un cod mai mult.

Duck, haideți să o rupem, doar pe exemplele respective puteți arăta ce este bun și ce este rău.

O soluție foarte comună, am făcut-o singură

Inițializarea șoferului de unde să facă și de ce

dar cum faceți acum?)

Am facut si fac) Voi incerca, de asemenea, sa descriu o alta abordare interesanta din practica:
Există un driver de inițiere de lungă durată Singleton (ascuțit pe firefox)

Există, de asemenea, o clasă de mediuconfigurare de unde conducătorul auto este luată pentru utilizare ulterioară

Apare pagina abstractă în care sunt colectate metodele comune de lucru cu paginile și se creează un config în designer, care la rândul său strânge șoferul

Apoi, din această pagină, toate paginile sunt moștenite. În test, se creează o pagină și se trimite o config.

Din moment ce am folosit jbehave apoi în clasa de test de bază config a fost ridicat astfel

în general, inițializarea driver-ului ar trebui făcută exclusiv în afara testelor și a obiectelor sau a componentelor paginii, dar în același timp face acest lucru pentru ca acest driver să fie folosit nu numai în BaseScreen. dar l-ați putea folosi și în alte clase. Abordările sunt o grămadă de lucruri diferite.

Cea mai mare problemă, probabil - este că, în BasePage trebuie să acumuleze toate metodele de lucru cu Paige, de multe ori să se stabilească așteptări, metode asociate cu un clic și alte lucruri, care nu este bun, pentru că este mai bine să împărtășiți pe acest principiu:

  • Metodele de lucru cu elementele sunt în clasa lor
  • așteptările lor
  • metode care sunt generalizate pentru reutilizare pe alte Scripturi sau cele mai multe - se află în baza de date

în primul rând nu există o moștenire multiplă, astfel încât să puteți moșteni doar baza de date. în care vor exista doar metode comune pentru toate capturile de ecran. Metodele de lucru cu elemente deja existente nu pot fi combinate. Se dovedește că este necesar sau să se contracteze sau să se facă moștenire cascadă: - UiElements este moștenit de la WaitingElementsts. Instrumentele de așteptare, la rândul lor, sunt moștenite de la BasePage în care Driverul este implementat și astfel conducătorul auto intră în teste.

Ajutor pot veni încă ajutoare, dar ele trebuie să fie trase, ceea ce face testul nu foarte frumos ..

Probabil că șoferul ar trebui să fie izolat de teste și de pagini, deoarece îl veți inițializa în diferite clase ale aplicației dvs. și peste tot ar trebui să funcționeze.

Chiar și pentru a face o captură de ecran a ascultătorului, trebuie să utilizați șoferul acolo. Iar testele în sine vor implementa deja implementarea cu acest driver. Asta înseamnă că nu trebuie să vă faceți griji în legătură cu șoferul, deoarece acest lucru va face cadrul pentru dvs.

Inițializarea driverului este, în esență, o chemare la getDriver

Inițializarea șoferului de unde să facă și de ce

Ne pare rău, pentru o pauză neplanificată.

Totuși, aș dori să aduc discuția într-un punct logic.

Deci, în opinia mea:
Condiția inițializării driverului este de a rula un test sau un grup de testare

Inițializarea șoferului de unde să facă și de ce

Șoferul nu este deloc necesar.
Driverul este necesar lângă paginile și componentele care lucrează cu paginile, iar driverul poate fi pur și simplu transferat acolo.

Sunt argumentele mai mult sau mai puțin adevărate?

Condiția pentru inițializarea driverului este de a rula un test sau un grup de testare

În primul rând, șoferul nu rulează teste, ci browserul. Testele rulează cadrul unității (de exemplu, testng / junit). Pentru șofer este important nu "ce", ci "unde și când". În acest caz, "în cazul în care" - într-un context izolate thread-safe. "Când" - de exemplu, înainte de [suite, test, clasă, metodă]. Aici, imediat și sarcina - pentru a înțelege când este cel mai bine pentru a ridica conducătorul auto.

Șoferul este necesar pagini de subdoză

Și de ce avem nevoie de un șofer? Paginile sunt stratul domeniului dvs., iar driverul este un cadru. Dacă duceți șoferul la nivelul paginii, nu este mai bine decât să îl utilizați în cadrul testelor.

În primul rând, șoferul nu rulează teste, ci browserul.

Da, am înțeles că șoferul nu rulează teste :). Vroiam să scriu că condiția inițializării driverului rulează teste. Am rulat testele, iar șoferul ar trebui să înceapă. Cum încă nu este important.

Și de ce avem nevoie de un șofer? Paginile sunt stratul domeniului dvs., iar driverul este un cadru. Dacă duceți șoferul la nivelul paginii, nu este mai bine decât să îl utilizați în cadrul testelor.

Paginile necesită un driver, deoarece metodele paginilor care folosesc driverul fac ceva la nivelul de bază - metodele vă permit să lucrați cu elemente de pagină și să efectuați anumite acțiuni. Cum puteți minimiza dependența paginii de driver?

Paginile au nevoie de un driver, deoarece metodele paginilor care folosesc driverul fac ceva la nivelul de bază

Ie dacă aveți 10 pagini, și tot ce trebuie să introduceți orice valoare în câmpul de introducere, veți duplicat fiecare pagină driver.findElement (Locator) .sendKeys (text) în ceea ce privește fiecare domeniu, nu?







Articole similare

Trimiteți-le prietenilor: