Testarea integrării - documentație de bază 1

Testarea integrării asigură funcționarea corectă a componentelor aplicației atunci când sunt asamblate împreună. ASP.NET 5 acceptă testarea de integrare utilizând cadre de testare și o gazdă de testare încorporată care poate fi utilizată pentru a procesa cererile fără încărcare în rețea.







Introducere în testarea integrării¶

Testele de integrare verifică dacă diferitele părți ale aplicației funcționează corect. Spre deosebire de testele de integrare a testelor de unitate, adesea solicită componente ale infrastructurii de aplicații, de exemplu, o bază de date, un sistem de fișiere, solicitări web și răspunsuri și așa mai departe. În locul acestor componente, testele de unitate folosesc obiecte machete, iar testele de integrare ar trebui să verifice dacă aceste componente funcționează bine în sistem.

Deoarece testele de integrare funcționează cu segmente de coduri mari și pentru că au nevoie de elemente de infrastructură, ele sunt mai lent decât testele unitare. Prin urmare, nu trebuie să utilizați prea multe teste de integrare, mai ales dacă puteți testa unele funcționalități cu un test de unitate.

Dacă același comportament poate fi testat utilizând un test de unitate și un test de integrare, selectați un test de unitate, deoarece va fi întotdeauna mai rapid. Puteți avea sute de unități de testare, dar numai câteva teste de integrare care acoperă cele mai importante scenarii.

Testarea logicii în interiorul metodelor este, de obicei, o sarcină de testare a unității. Și testele de integrare sunt incluse în joc atunci când trebuie să verificați modul în care funcționează aplicația într-un cadru (de exemplu, ASP.NET Core) sau cu o bază de date. Nu este nevoie să creați prea multe teste de integrare pentru a verifica dacă puteți să adăugați o înregistrare sau să o extrageți din baza de date. Nu este nevoie să testați toate modificările posibile ale codului pentru a accesa datele - trebuie doar să vă asigurați că aplicația funcționează corect.

Testarea integrării în ASP.NET Core¶

Pentru a configura testele de integrare, trebuie să creați un proiect de testare care este asociat cu proiectul web ASP.NET Core web și să stabiliți un mecanism pentru executarea testelor. Acest proces este descris în documentația Unității de testare. împreună cu instrucțiuni mai detaliate pentru efectuarea testelor și recomandări pentru testarea numelor și a claselor de testare.

Testele de testare și testele de integrare trebuie stocate în diferite proiecte. Apoi nu includeți în mod accidental elementele de infrastructură în testele unității și apoi puteți executa fie toate testele, fie un anumit set de teste.

Testați gazda

ASP.NET Core include o gazdă de testare care poate fi adăugată la proiectele de testare de integrare și utilizată pentru a găzdui aplicațiile ASP.NET Core, procesând interogări de testare fără a avea nevoie de gazduire web reală. În acest exemplu, am inclus un proiect de testare a integrării care va folosi "xUnit" și o gazdă de testare, după cum puteți vedea mai jos:

După ce pachetul Microsoft.AspNet.TestHost este inclus în proiect, aveți posibilitatea să creați și să configurați TestServer. Următorul test arată cum se verifică, apoi cererea trimisă în directorul rădăcină al site-ului returnează "Hello World!", Iar acest test ar trebui să treacă cu succes pentru șablonul implicit ASP.NET Core Empty.







Aceste teste utilizează modelul Arrange-Act-Assert, dar în acest caz, pasul Arrangere apare în constructorul care creează instanța TestServer. Aici WebHostBuilder va fi folosit pentru a crea TestHost; în acest caz, trecem metoda de configurare din clasa de pornire SUT. Această metodă este utilizată pentru a configura fluxul de cereri TestServer identic cu modul în care serverul SUT va fi configurat.

În partea de testare Act, instanța TestServer este interogată pentru calea "/", iar răspunsul este citit într-un șir. Această linie este apoi comparată cu linia "Hello World!" Așteptată. Dacă sunt aceleași, testul va avea succes, în caz contrar - nu.

Putem adăuga câteva teste de integrare suplimentare pentru a verifica dacă aplicația web are funcționalitatea verificării primare:

Rețineți că nu încercăm să testați validitatea mecanismului nostru de verificare primară, trebuie doar să vedem că aplicația web face ceea ce așteptăm. Avem deja teste unitare care lucrează cu PrimeService. după cum puteți vedea:

Testarea integrării - documentație de bază 1

Despre testele unității puteți afla mai multe în articolul Testul unității.

Acum este momentul să ne gândim dacă ne place cum arată aplicația noastră. Dacă vedem un cod mirositor. merită să refacem aplicația pentru ao îmbunătăți.

Refactorizarea de a folosi middleware

Refactorizarea este procesul de schimbare a codului aplicației pentru a-și îmbunătăți aspectul fără a-și schimba comportamentul. În mod ideal, refactorizarea ar trebui făcută atunci când aveți un set de teste parcurse, deoarece atunci veți ști că comportamentul sistemului va fi același înainte și după modificări. Dacă vă uitați la modul în care logica verificării primare este implementată în aplicația noastră, vedem următoarele:

Acest cod funcționează, dar este departe de modul în care am dori să implementăm o astfel de funcționalitate în aplicația ASP.NET Core, chiar și la fel de simplă ca a noastră. Imaginați-vă cum va arăta metoda Configure. dacă trebuie să scriem mai multe coduri în el de fiecare dată când adăugăm un alt punct final pentru adresa URL!

Putem adăuga la aplicația MVC și vom crea un controler care să se ocupe de validarea inițială. Dar acest lucru este un pic prea mult, deoarece momentan nu avem nevoie de o altă funcționalitate MVC.

În plus, putem folosi middleware ASP.NET. și apoi putem încapsula logica testului primar într-o clasă separată și să obținem o mai bună separare a responsabilității în cadrul metodei Configure.

Vrem ca calea middleware să fie specificată ca parametru, astfel încât clasa așteaptă RequestDelegate și PrimeCheckerOptions în constructorul său. Dacă calea de solicitare nu se potrivește cu cea care se așteaptă să vadă middleware-ul, sunăm pur și simplu următorul middleware din lanț. Restul codului din Configurare. acum este în Invoke.

Deoarece middleware-ul nostru depinde de serviciul PrimeService. solicităm de asemenea constructorului o instanță a acestui serviciu. Cadrul va oferi acest serviciu prin Injecția de dependență. și presupunem că este configurat (de exemplu, în ConfigureServices).

Deoarece modulul middleware funcționează ca un punct final în lanțul delegat de interogare, dacă calea se potrivește, atunci _next.Invoke nu va fi apelat dacă acest middleware gestionează cererea.

Când legarea Poe este în vigoare și sunt create câteva metode de extensie utile pentru a facilita configurarea, după refactorizare, metoda Configure arată astfel:

După refactorizare, știm, de asemenea, că aplicația funcționează ca și înainte, deoarece testele de integrare au avut succes.

De asemenea, este bine să faceți schimbări după ce ați refacturat și toate încercările au avut succes. Dacă faceți exercițiul Test Driven Development, adăugați un angajament la ciclul Red-Green-Refactor.

Testarea de integrare oferă un nivel mai ridicat de verificare decât testarea unității. La integrarea testelor, testăm infrastructura și modul în care diferitele părți ale aplicației lucrează împreună. ASP.NET Core oferă TestServer. care simplifică foarte mult lansarea testelor de integrare.

Resurse suplimentare¶







Trimiteți-le prietenilor: