Share
Testarea este deseori neglijată în programare, iar dezvoltarea web nu este diferită. Mulți dezvoltatori nu au realizat încă că testele automate vă pot face mai productivi, mai puțin stresați și mai încrezători în ceea ce privește codarea caracteristicii următoare. În acest articol, ne vom concentra pe utilizarea seleniului pentru a automatiza testarea browserului.
În calitate de dezvoltatori web, avem nevoie de teste de un fel, deoarece cu siguranță nu vrem ca rapoartele de eroare de la utilizatorii aplicațiilor noastre să fie mijloacele noastre de testare. Vrem să fie teste Automated deoarece testarea manuală, deși uneori un rău necesar, este lentă, predispusă la erori și plictisitoare. Testarea manuală repetată a unei aplicații Web în mai multe browsere poate fi, sincer, distrugerea sufletului! Un instrument precum Selenium vă poate face dependenți de testele automate.
Poate că vă puteți referi la această experiență: vă deschideți proiectul cu intenția de a codifica o nouă caracteristică sau de a repara un bug și vă întrebați: "Ar putea modificările pe care urmează să le fac să aibă efecte secundare nedorite? ?“
Această teamă de a face schimbări se agravează doar pe măsură ce progresează proiectul și deseori ruinează distracția codării.
Dar, dacă aveți un set bun de teste automate și le executați frecvent, aveți șansa să știți foarte repede dacă ați încălcat codul. Acest lucru vă oferă un sentiment de încredere mai degrabă decât unul de frică, ceea ce vă permite să purtați pur și simplu cu ceea ce trebuie să faceți, indiferent dacă aceasta este implementarea de noi caracteristici, fixarea de bug-uri sau refactorizarea. E foarte răcoritoare.
Acest lucru este mai ușor de înțeles atunci când ați trecut prin durerea de programare fără teste bune. Este tentant să ne gândim: "Vreau doar să continui codarea următoarei părți a cererii mele". Acest lucru este adesea mai mult atunci când lucrați la ceva relativ simplu. Dar cum vă poate spune orice dezvoltator, lucrurile pot deveni rapid mai complexe. Dintr-o dată este groaznic să modificați codul și atunci apreciați cu adevărat un set cuprinzător de teste care vă sprijină.
Dar reducerea fricii este doar un beneficiu. Testele bine scrise acționează pentru a documenta sistemul în curs de dezvoltare și acest lucru promovează o mai bună înțelegere între dezvoltatori și clienți. Privind la un test, ar trebui să puteți spune exact cum trebuie să se comporte un anumit aspect al sistemului. Acesta este un concept subliniat de Dezvoltare condusă de comportament (discutat mai târziu).
O idee importantă este că examinarea modului de testare a aplicației dvs. este la fel de importantă ca și modul în care faceți acest lucru. Asta merită să se reamintească: gândirea cum să testați sistemul dvs. este la fel de importantă și de modul în care scrieți codul aplicației.
Este o schimbare majoră în gândire, dar odată ce vă aflați în modul în care vedeți testele automate ca o parte fundamentală a programării și ați câștigat beneficiile, nu vă veți uita niciodată înapoi. Am devenit dependent de testarea în timp ce am fost introdus în TDD, dar în mintea mea, fiind infectat cu test, nu vine neapărat prin TDD sau prin testarea unității. Trebuie doar să fi experimentat valoarea enormă a testelor automate și să te simți ciudat în ceea ce privește programarea dacă nu în rutina de a le scrie.
Odată ce vă aflați în modul de gândire și ați câștigat beneficiile, nu vă veți uita niciodată înapoi
Un răspuns la aceste argumente ar putea fi: "Toate astea sună ca ceva care ar lua mult timp, timp care ar putea fi codarea următoarei caracteristici". La urma urmei, în mod normal, avem un timp limitat de petrecere a unui proiect. Și este adevărat, instalarea și compunerea testelor automate necesită timp și efort. Dar timpul pe care îl economisește pe termen lung și calitatea îmbunătățită pe care o are în mod obișnuit la cod, face ca o rutină riguroasă de testare automată să merite investiția.
Vom folosi un instrument gratuit numit Selenium. Seleniul automatizează browserele; simulează un utilizator care interacționează cu aplicația dvs. Web, execută clicuri de mouse, introducere de text și chiar drag-and-drop (printre altele). Poate fi folosit și pentru a verifica ce este afișat pe ecran.
Știind cum să scrii teste bune este o abilitate pe care o dezvolți de-a lungul timpului, dar în acest tutorial vom discuta despre pornirea testării browserului folosind Selenium.
Dacă sunteți nou la testare, este util să obțineți o idee generală despre tipurile de teste utilizate în mod obișnuit. Diferite tipuri de teste sunt utilizate în scopuri diferite. Rețineți că terminologia din jurul testelor este oarecum inconsistentă - oamenii folosesc același termen pentru a însemna lucruri ușor diferite.
Teste unitare sunt folosite pentru a verifica corectitudinea claselor, metodelor și funcțiilor individuale. Codul existent ar trebui să fie păstrat izolat de alte părți ale sistemului și acest lucru este realizat folosind substitutele pentru lucrurile pe care depinde codul de test. În acest fel, este ușor să vedem unde apare problema când un test nu reușește. Testele unităților tind să fie cele mai rapide teste pentru a rula și nici un cod implicat nu ar trebui să facă lucruri cum ar fi lovirea unei baze de date sau accesarea rețelei.
Testarea unităților nu ar trebui să se refere la verificarea funcționării corecte a componentelor individuale ale sistemului; acolo intră testele de integrare.
Nivel scăzut teste de integrare s-ar putea ocupa de interacțiunea dintre două sau trei clase, în timp ce altele ar putea verifica dacă acest cod funcționează corect cu resurse externe, de exemplu o bază de date sau un server HTTP.
Teste de sistem, unde se află acest tutorial, sunt executate împotriva întregului sistem integrat pentru a verifica dacă sunt îndeplinite cerințele întregului sistem. Testele de sistem se pot referi la aspecte precum performanța și scalabilitatea, însă tipul de teste pe care ne vom concentra asupra relației dintre modul în care sistemul se comportă sau nu se așteaptă ca clientul să implementeze caracteristicile specificate. În cercurile de dezvoltare Agile, aceste teste se încadrează în categoria teste de acceptare.
Exemplul de cod prezentat mai jos face acest tip de testare. Aceste teste ne indică dacă cererea noastră se comportă așa cum ne dorește, din punctul de vedere al utilizatorului. Putem folosi Selenium pentru a automatiza testele de acest fel, deoarece poate simula un utilizator care interacționează cu sistemul (și poate face acest lucru folosind browsere Web reale, precum și sisteme fără cap, cum ar fi HtmlUnit).
Pentru că ne vom interesa doar ce sistemul face și nu Cum o face, vom fi angajați în testarea cutie neagră. De asemenea, merită remarcat faptul că, spre deosebire de cele mai multe alte tipuri de teste, testele de acceptare ar trebui să fie scrise în colaborare cu clienții.
Ce fel de teste ar trebui să utilizați?
Putem folosi Selenium pentru a automatiza testele deoarece poate simula un utilizator interactiv cu sistemul
Tortul este un fel de mâncare, dar majoritatea oamenilor (nu mine) ar sfătui să nu mănânce exclusiv; se completează mai degrabă decât înlocuiește alte alimente. Este important să rețineți că diferitele tipuri de testare se completează reciproc, în loc să fie în competiție. După cum am menționat mai sus, ele servesc scopuri diferite. Fiecare dintre ele are avantaje și dezavantaje și, cu siguranță, nu se exclud reciproc.
La nivel de sistem, testele bazate pe GUI, cum ar fi exemplele de mai jos, au tendința de a fi relativ lent și astfel nu oferă feedback rapid. De asemenea, testele de acest tip au o tendință de a fi fragile și deoarece ele ating atât de mult codul aplicației, urmărirea sursei unei defecțiuni poate fi dificilă fără un set cuprinzător de teste unitare și de integrare. De fapt, este o idee bună să aveți mai multe teste la nivel de unitate decât acelea pe care le folosiți Selenium pentru testele pe sistem, bazate pe GUI. Asta nu înseamnă că testele de seleniu nu sunt utile! Ideea este că niciun tip de testare nu este suficient de unul singur.
Vom folosi Selenium 2. Mai exact, vom folosi WebDriver, o componentă a Selenium 2. WebDriver înlocuiește API-ul Selenium 1 Remote Control (RC) API și oferă o serie de avantaje față de RC. De exemplu, este mai bine să testați AJAX și are un API mai curat și mai orientat spre obiect. De asemenea, funcționează într-un mod complet diferit față de RC. Mai degrabă decât să utilizeze JavaScript pentru a interacționa cu o pagină, WebDriver folosește interfața de automatizare a browserului care este specifică fiecărui browser. Rezultatul este că simulează mai bine un utilizator efectiv care interacționează cu Website-ul testat.
O altă componentă a Selenium este IDE, un instrument de înregistrare și redare și un plugin Firefox. Nu necesită cunoașterea programării și este utilă pentru testarea exploratorie.
Testele sale tind să fie mai fragile decât scripturile RC și WebDriver și un dezavantaj evident este că poate fi folosit numai în Firefox. IDE este conceput ca un instrument prototip și nu este recomandat pentru teste serioase.
WebDriver acceptă o mare varietate de browsere, inclusiv Chrome, IE, iOS și Android. Mai târziu, vom examina utilizarea serviciilor de testare în cloud, pentru ca testele să poată fi executate în combinații de sisteme de operare browser care ar putea să nu aibă alt acces la.
Aici, WebDriver va fi folosit cu Python, dar sunt disponibile mai multe legături lingvistice, inclusiv cele pentru Java, C # și PHP. Dacă nu sunteți familiarizați cu Python, nu vă temeți, ar trebui să aveți în continuare posibilitatea de a urmări împreună cu exemplele, pe măsură ce citește cam mult pseudo-codul.
Python ... citește cam mult pseudo-codul
Sunt disponibile și alte interfețe, dar avem nevoie de cele două părți cheie ale API-ului WebDriver WebDriver și WebElement. Fiecare exemplar de mai jos va funcționa cu WebDriver obiect, care corespunde browserului și unul sau mai multe obiecte de tip WebElement, care reprezintă elemente pe o pagină.
Metodele de localizare a elementelor pe o pagină (discutate mai târziu) sunt comune între aceste două interfețe. Pe de altă parte, metode precum nume eticheta sunt disponibile numai pe WebElement. În mod similar, are sens și pentru metode precum get_cookies și reîmprospăta să fie disponibil pe WebDriver dar nu pe WebElement, și acest lucru este adevărat.
Este interesant de observat că există un efort de a face WebDriver un standard W3C.
În prezent, Selenium 2 acceptă Python 2.6 și Python 2.7, deci instalați unul dintre acestea dacă aveți nevoie. Pentru a afla ce versiune aveți, la tipul de linie de comandă python -V. Utilizatorii Linux și Mac au în mod normal Python, dar ar trebui să aibă grijă atunci când își actualizează versiunea de Python, deoarece sistemul de operare poate depinde de versiunea cu care a venit OS.
Odată ce aveți Python 2.6 sau 2.7, cel mai bun mod de a instala pachete pentru el este cu pip. Odată ce ați pip, pentru a instala tipul Selenium 2: pip instalare-U seleniu. (-U va actualiza orice versiune anterioară pe care o puteți avea. Utilizatorii Linux și Mac ar putea avea nevoie sudo).
Pentru a obține pip pe Windows, consultați această întrebare privind depășirea stivei.
De asemenea, vom folosi Firefox, deoarece browserul care funcționează cu WebDriver este scos din cutie.
Avem nevoie de o aplicație Web pentru a testa și vom folosi un număr simplu de ghicit joc. Este un program deliberat de simplu. O aplicație Web este adesea testată pe o mașină a dezvoltatorului folosind un server web de dezvoltare local, deoarece este convenabil pentru testarea înainte de implementare. Cu toate acestea, în acest caz vom rula teste împotriva unei aplicații Web implementate: http://whats-my-number.appspot.com. Aceasta va fi aplicația testată (AUT). (În cazul în care acest site este în jos, încercați http://whats-my-number-backup.appspot.com/).
Răspunsul (îmi pare rău să distrug distracția) este 42.
Oricare ar fi intrarea utilizatorului, ar trebui să fie afișat un indiciu. Programul așteaptă numere întregi de la 0 la 100 (inclusiv) și în cazul în care utilizatorul introduce o valoare care nu se încadrează în această regulă, indicatorul ar trebui să recomande această cerință. Când utilizatorul încearcă să ghicească un număr întreg de la 0 la 100, care este incorect, sugestia arătată ar trebui să fie "prea mică" sau "prea mare". Când este introdus 42, "Felicitări" ar trebui să fie indicatorul afișat.
Ceea ce am atins mai devreme este ideea că o modalitate foarte bună de a fi explicită cu privire la modul în care un sistem ar trebui să se comporte este să scrie teste, iar exemplele ulterioare vor implica un set destul de cuprinzător de teste care vor acționa pentru a comunica comportamentul intenționat al sistemului. Vom avea o formă de documentație executabilă.
Vom avea o formă de documentație executabilă
Unul dintre marile lucruri despre o limbă precum Python este că puteți utiliza un interpret interactiv. Pentru a rula interpretul interactiv Python pur și simplu tastați piton la linia de comandă și ar trebui să vedeți promptul său (>>>). Alternativ, pentru a rula un fișier script, utilizați python script_name.py
Nu este modul în care rulează în mod obișnuit codul de testare, dar când începeți cu automatizarea browserului, poate fi util să utilizați interpretul interactiv și să tastați o linie de Python la un moment dat. În acest fel, este mai ușor să obțineți o simțire a modului în care WebDriver controlează browserul și simulează un utilizator real. Deși puteți rula în schimb un fișier de script și stați înapoi și urmăriți în timp ce Selenium face lucrurile sale, lucrurile funcționează într-un ritm mult mai rapid decât cu un utilizator uman, astfel încât rularea comenzilor într-o singură linie simplifică aprecierea comenzile pe care le emiteți fac de fapt. Este o modalitate foarte bună de a învăța și de a experimenta.
Introduceți următoarele linii de cod la solicitarea interpretului, apăsând Enter după fiecare. Primul pas este să efectuați un import:
de la seleniul import webdriver
Apoi, deschideți o fereastră de browser și vizitați AUT:
Accentsconagua
browser = webdriver.Firefox () browser.get ('http://whats-my-number.appspot.com/') Acum vom face ceva care face acest test. Python a fost construit afirma instrucțiunea poate fi utilizată pentru a verifica dacă ceva este adevărat și în acest caz îl folosim pentru a verifica dacă titlul paginii este "Ce este numărul meu". Acest lucru poate fi denumit test de conținut:
afirmați "Care este numărul meu?" == browser.title
Din moment ce titlul paginii este corect, Python ne dă un alt prompt. Titlul ar fi fost incorect afirma aruncarea unui AssertionError. Un AssertionError în timp ce rulați un fișier script face ca programul să se prăbușească (ceea ce este util).
Următoarea parte a testului nostru este ceea ce documentația Selenium numește un test de funcționare. Vrem să verificăm că atunci când este introdus 1 ca o presupunere, programul răspunde cu conținut care include un indiciu care indică faptul că estimarea este prea mică. Exemple mai vechi vor aborda mai multe intrări de utilizator.
Pentru a face acest lucru, trebuie să completați formularul. Dacă vă uitați la codul HTML al paginii de joc ghicitoare, veți vedea că câmpul de introducere a textului are a Nume atribuiți cu valoarea "ghiciți". Acest lucru poate fi folosit pentru a obține o WebElement obiect pentru a reprezenta câmpul de intrare:
guess_field = browser.find_element_by_name ("ghici") Acum putem scrie în ghici. WebElement are o send_keys metodă:
guess_field.send_keys ( '1')
Am gasit butonul de trimitere si facem clic pe el sau putem folosi imaginea furnizata a depune , dar în loc să apăsați tasta Return:
din selenium.webdriver.common.keys import Keys guess_field.send_keys (Keys.RETURN)
Formularul este trimis și pagina este reîncărcată (AJAX nu este în uz) și, deoarece estimarea este prea mică, "Parerea dvs. este prea mică" ar trebui afișată undeva în corpul documentului. Pentru a verifica acest lucru mai întâi avem nevoie de o WebElement obiect care reprezintă HTML corp:
body = browser.find_element_by_tag_name ('body') text proprietatea WebElement va dezvălui în acest caz textul paginii. Să folosim asta într-un an afirma afirmație:
afirmați "Parerea dvs. este prea mică" în body.text
Din nou, succes, așa că Python ne dă un alt prompt. Deoarece aceasta este o ghicire incorectă, "Felicitări" nu este de văzut nicăieri:
afirmați "Felicitări" nu în body.text
În cele din urmă închidem instanța Firefox pe care o folosim:
browser.quit ()
Dacă sunteți familiarizați cu programarea folosind JavaScript și DOM, veți ști despre necesitatea de a obține referințe la elementele DOM pe o pagină Web și, după cum am văzut, trebuie să facem ceva similar aici. Cele două situații nu sunt totuși exact aceleași, deoarece, mai degrabă decât obținerea unei referințe la un element DOM, obținem a WebElement obiect care corespunde unui element DOM.
Mai sus am folosit
find_element_by_name, care este utilă pentru elementele de formă, precum șifind_element_by_tag_name. Alte metode de localizare includfind_element_by_idșifind_element_by_css_selector. Consultați documentația Selenium pentru lista completă.
Din punct de vedere al performanței, folosind un identificator de elemente sau un localizator de nume (așa cum am făcut mai sus) este cea mai bună modalitate de a selecta un element. Desigur, odată ce avem a WebElement obiect care corespunde elementului DOM dorit este obișnuit să doriți să interacționați cu el într-un fel, ceea ce este în cazul în care metode cum ar fi send_keys și clic sunt utile.
Testele tricotate sunt periculoase, deoarece, dacă testele uneori nu reușesc, de fapt, când ar trebui să treacă, veți ignora rezultatele testelor și întregul proces de testare devine devalorizat.
În fișierul zip descărcabil care însoțește acest tutorial, ftests1.py afișează codul de testare de mai sus sub forma unui fișier de script. Cu toate acestea, există o omisiune: ați putea observa că apelul către implicitly_wait, inclus în ftests1.py, nu a fost listat sau discutat.
Dacă executați un test împotriva unui sistem de zece ori, ar trebui să vă dați același rezultat, fiecare dintre acestea de zece ori. Cu toate acestea, testele fragile și nesigure, de tipul celor pe care le facem, sunt destul de frecvente și este posibil să întâlniți această problemă pe măsură ce experimentați testul de seleniu. Încercările tricotate sunt periculoase, deoarece, dacă testele nu reușesc uneori să treacă, de fapt, trebuie să ignori rezultatele testelor și întregul proces de testare devine devalorizat. implicitly_wait este un instrument foarte util în combaterea testelor fragile și din acest punct un apel către implicitly_wait va fi folosit în toate exemplele de cod.
Fiind un dezvoltator infectat cu test, veți dori să știți despre instrumentele xUnit. Ele sunt disponibile pentru multe limbi de programare. unittest este un instrument xUnit care vine ca standard cu Python. Poate părea confuz, dar, deși nu scriem teste unitare, unitatea test este utilă. De exemplu, testul unitar ajută la structurarea și rularea testelor, iar eșecurile de testare au ca rezultat mesaje mai utile.
Versiunea unittest în Python 2.7 are caracteristici suplimentare în comparație cu versiunile mai vechi (unele dintre acestea vom folosi), deci dacă executați Python 2.6, va trebui să instalați backport-ul: pip install unit test2
Codul de mai jos este o versiune cu test unitate a codului de testare prezentat mai devreme.
Ca și înainte, se bifează titlul ferestrei browserului, 1 este încercat ca o presupunere și răspunsul programului este verificat:
încercați: import unittest2 ca unitatetest # pentru Python 2.6 cu excepția ImportError: import unitatetest de la selenium import webdriver de la selenium.webdriver.common.keys import Chei de clasă GuessTest (unittest.TestCase): def setUp (self): self.browser = webdriver.Firefox () self.browser.implicitly_wait (3) def tearDown (self): self.browser.quit () def test_should_see_page_title (self): # Brian vizitează site-ul jocului ghicit self.browser.get ('http: // whats-my -number.appspot.com/ ') # El vede că "Care este numărul meu?" este titlul paginii self.assertEqual ('What's My Number?', self.browser.title) def test_should_get_correct_hint_from_guess_too_low (auto): # Brian vizitează site-ul jocului ghicit self.browser.get ('http: // whats-my-number.appspot.com/ ') # El își formulează ghicitul în câmpul de formular și lovește cheia de întoarcere guess_field = self.browser.find_element_by_name (' guess ') guess_field.send_keys (' 1 ') guess_field.send_keys ( Keys.RETURN) # Pagina este reîncărcată și din moment ce estimarea este prea mică, se afișează # 'autoarele tale prea mici' body = self.browser.find_element_by_tag_name ('body') self.assertIn (" , body.text) # Deoarece aceasta este o estimare incorectă, "Felicitări" nu este niciodată de văzut self.assertNotIn ("Felicitări", body.text) dacă __name__ == '__main__': unittest.main () Brain este numele "robotului nostru". Vezi si ftests2.py în fișierul zip care însoțește acest tutorial.
Testele individuale sunt metode ale clasei GuessTest, care moștenește de la unittest.TestCase. Pentru mai multe idei despre de sine cuvinte cheie și alte aspecte orientate pe obiecte ale Python, vedeți sesiunea Nettuts pe Python. Numele metodei de test trebuie să înceapă cu literele Test. Este esențial să descrieți numele metodelor.
Desigur, un afirma este esențială pentru orice încercare, dar, de fapt, mai degrabă decât utilizarea afirma declarație ca înainte de a avea acces la metode de assert assert. În acest caz assertEqual, assertIn și assertNotIn sunt folosite.
înființat și dărâma metodele sunt executate înainte și după fiecare dintre metodele de testare și aici le folosim pentru a porni și a închide o instanță a browserului WebDriver.
Blocul final, dacă __name__ == '__main__': unittest.main (), permite acest script unitatetest să fie rulat din linia de comandă. Pentru a rula scriptul mergeți la directorul care conține ftests2.py și tip: python ftests2.py. Realizarea trebuie să aibă ca rezultat o ieșire asemănătoare:
În mod ideal, testele ar trebui să eșueze "zgomotos", dar să treacă "în liniște" și, după cum puteți vedea, exact ceea ce face unitatea: doar o perioadă este tipărită pentru fiecare metodă de testare care trece. În cele din urmă vedem un bun venit "OK" (nu ar trebui să fie "bine făcut"?).
După cum puteți vedea, principiul "Nu repetați-vă" este încălcat, deoarece URL-ul AUT este în cod de două ori. Testarea detaliată permite refactorizarea codului aplicației, dar nu uitați de codul de test refactor.
Până acum, testele noastre au implicat doar o singură estimare: 1, și în mod clar acest lucru nu este foarte cuprinzător. Următorul scenariu va face ceva despre asta, vezi ftests3.py în fișierul zip.
importdeclarații, declarație de clasă,înființatșidărâmametode, șidacă __name__ == '__main__':bloc, sunt exact la fel ca ultimul exemplu. Deci, să ne concentrăm asupra lucrurilor diferite.
Deoarece acest lucru este ceva ce vom face în mod repetat, completarea formularului a fost pusă în propria sa metodă de ajutor, numită _enter_guess_hit_return:
def _enter_guess_hit_return (auto, ghici): guess_field = self.browser.find_element_by_name ('guess') guess_field.send_keys (guess) guess_field.send_keys (Keys.RETURN) O altă metodă de ajutor, _unsuccessful_guess, se ocupă cu vizitarea AUT, chemând _enter_guess_hit_return, și apelând la metodele de afirmare. Din nou, utilizatorul nostru de robot ar putea face cu un nume, de data aceasta să-l referim la el ca pe Bertie.
def _unsuccessful_guess (self, berties_guesses, expected_msg): self.browser.get ('http://whats-my-number.appspot.com/') pentru berties_guess în berties_guesses: self._enter_guess_hit_return (berties_guess) body = self.browser. find_element_by_tag_name ('body') auto.assertIn (expected_msg, body.text) self.assertNotIn ('Felicitări', body.text) S-ar putea să observați că sunați _enter_guess_hit_return și efectuarea afirmațiilor se întâmplă într-o buclă. Acest lucru se datorează faptului că ne întoarcem berties_guesses, care este o listă. berties_guesses vor fi transmise acestei metode prin metodele de testare a apelului, care vor transmite și un mesaj așteptat, expected_msg.
Acum, pentru a face uz de ajutoarele noastre în metodele de testare:
def test_should_get_correct_hint_from_guess_too_low (auto): berties_guesses = ['0', '01', '17', '23', '041'] expect_msg = 'Parerea ta este prea mică' ): berties_guesses = ['43', '80', '100'] expect_msg = 'Parerea ta este prea mare` self__uccessful_guess (berties_guesses, expected_msg) def test_should_get_correct_hint_from_invalid_input (self) , 'c7', '1,2', '9,9778', '-1', '-10', '101', 'hkfjdhkacoe'] expected_msg = 'Vă rugăm să furnizați un număr întreg de la 0 la 100' expected_msg)
Pentru brevet, verificarea titlului paginii a fost eliminată. Desigur, ar trebui să existe o metodă de verificare a faptului că, atunci când se oferă estimarea corectă, "Felicitări" este într-adevăr afișată și sunteți invitat să scrieți această metodă (va fi distractiv, vă promit!).
Ultimul script de exemplu ne oferă un grad înalt de încredere că AUT funcționează așa cum ar trebui. Dar să presupunem că codul aplicației trebuie să se schimbe acum. De exemplu, clientul dorește o nouă caracteristică sau vrea să refacă, sau poate că unitățile sau testele de integrare au descoperit o greșeală pe care testele la nivel de sistem nu le-au dezvăluit (și acum dorim să remediem această defecțiune). În timpul procesului de modificare a codului, testele existente ar trebui să fie executate frecvent, astfel încât problemele să apară mai devreme decât mai târziu.
Să simulam o modificare a codului aplicației. O versiune modificată a jocului este la adresa http://whats-my-number-broken.appspot.com și dacă rulați ftests3.py împotriva acestei versiuni veți vedea o încercare de eșec:
test_should_get_correct_hint_from_guess_too_high eșuează. Testul arată că în modificarea codului aplicației a fost introdusă o regresie. Realizăm în mod regulat testele și trebuie să luăm în considerare doar modificările care au avut loc de la ultima încercare pentru a restrânge problema. În acest fel, încercările de scriere ne-au răsplătit cu o încredere sigură, spre deosebire de un sentiment de frică.
Aplicațiile Web sunt, în general, de așteptat să funcționeze corespunzător pe o mare varietate de browsere, deci este în mod normal cel mai bine să testați cu cât mai multe browsere pe cât mai multe platforme pe care le puteți pune mâna pe. Când se descoperă o problemă cu un sistem, nu este neobișnuit să auzi un dezvoltator spunând: "Ei bine, funcționează pe mașina mea". Aceasta deseori înseamnă: "Nu am testat-o corect". În cazul jocului de ghicire a numărului, vă puteți întreba dacă este necesară testarea browserului încrucișat, dar este, desigur, un sistem simplu deliberat.
Serviciile bazate pe cloud, cum ar fi Sauce Labs, vă pot ajuta. Sauce Labs oferă o varietate de combinații de browser-OS. Un alt serviciu este Testingbot, care oferă teste pe platforme mobile.
După cum ați văzut, facem teste împotriva unui site accesibil publicului, dar pentru site-urile aflate încă pe site-uri de dezvoltare și intranet, Sauce Labs oferă Sauce Connect și Testingbot Tunnel.
Probele de cod până acum au fost codificate cu greu pentru a utiliza Firefox. ftests3_remote.py, disponibil în fișierul zip, este o versiune îmbunătățită de ftests3.py care poate fi ușor configurat să ruleze folosind o combinație de browser-OS (în limitele a ceea ce este oferit de oricare dintre serviciile de testare în cloud pe care le folosim). Platforma, browserul și versiunea browserului sunt specificate pe linia de comandă atunci când scriptul este rulat.
Probele de cod până acum au fost codificate cu greu pentru a utiliza Firefox
Va trebui să vă înscrieți pentru un serviciu ca Sauce Labs sau TestingBot pentru a obține o cheie API și pentru a edita înființat (așa cum se arată în fișier) pentru a include această cheie. Ambele servicii pot fi judecate gratuit.
ftests3_remote.py se așteaptă ca platforma să fie primul argument al liniei de comandă, numele browserului secundar necesar, iar versiunea browserului este așteptată ultima dată. Referindu-ne la combinațiile browser-OS disponibile ale Sauce Lab, am putea, de exemplu, să executați scenariul după cum urmează:
python ftests3_remote.py LINUX crom
În cazul particular al Chrome, nu trebuie specificat nici un număr de versiune. Pentru a utiliza Internet Explorer, deoarece numele browser-ului este format din două cuvinte, trebuie folosite citate. De exemplu, să conducem testele folosind vechiul nostru prieten, IE6:
python ftests3_remote.py XP 'internet explorer' 6
Rezultatele testului sunt trimise la terminal, la fel ca și când ați efectuat testele pe mașina proprie. Cu toate acestea, vă puteți aștepta ca acest script să ruleze mai încet decât scripturile de test anterioare. Interesant, laboratoarele Sauce vă permit să vizionați un videoclip al fiecărui test care rulează odată ce este complet.
Un script de shell ar putea fi ușor creat pentru a rula ftests3_remote.py de mai multe ori, de fiecare dată cu o combinație diferită de platformă-browser-versiune.
Anterior ne-am uitat la nevoia implicitly_wait. Este interesant să rețineți că valoarea a trecut implicitly_wait așa cum este sugerat de exemplul propriului exemplu al lui Sauce Lab, este de 30 de secunde.
