Versiunea rusă a acestui articol puteți găsi aici.
Testarea nu este întotdeauna distractivă și interesantă. Acest proces este de obicei destul de lung și, uneori, plin de muncă monotonă. Se pare că nu cu mult timp în urmă, programatorii au folosit o ieșire standard sau un debugger pentru testarea clasei java.
În acest articol voi descrie biblioteca JUnit 4, care în multe moduri simplifică și automatizează procesul de scriere a testelor.
Pentru a demonstra principalele caracteristici ale cadrului JUnit, vom scrie o clasă primitivă în limba Java și o să ne batem. Această clasă va avea două metode - găsirea factorială a unui număr non-negativ și suma a două numere. În plus, instanța de clasă va conține contorul de apeluri pentru metodă.
Acum scrieți testele unității. Pentru aceasta, creați o clasă cu câteva metode de testare. Firește, o clasă poate conține metode de ajutor obișnuite. Pentru testele runner pentru a determina cine este cine, metodele de testare trebuie să fie marcate cu adnotare @Test.
Adnotarea poate include astfel de parametri:
- așteptat - specificați care excepție va fi generată de metodă (a se vedea exemplul de mai jos);
- timeout - după ce timp, în milisecunde, pentru a opri testul și pentru ao număra ca nereușită.
Dacă doriți să specificați că un anumit test trebuie să fie omis, atunci marcați-l cu adnotarea @Ignore. Deși puteți șterge adnotarea @Test.
Se întâmplă că pentru fiecare scenariu de testare aveți nevoie de un anumit context, de exemplu, instanțe de clase pre-create. Iar după executare este necesară eliberarea resurselor rezervate. În acest caz, aveți nevoie de @ înainte și după adnotări. Metoda marcată cu "Înainte de execuție" va fi executată înainte de fiecare caz de testare, iar metoda marcată cu @ După este după fiecare caz de test.
Dacă inițializarea și eliberarea de resurse ar trebui să se facă doar o singură dată - înainte și după toate testele - atunci utilizați o pereche de adnotări @BeforeClass și @AfterClass.
Și aici este clasa de testare în sine cu mai multe scenarii de testare:
Metoda apelurilor testează corectitudinea contorului de apeluri. Metoda factorială verifică corectitudinea calculului factorial pentru unele valori standard. Metoda factorialNegativ verifică faptul că IllegalArgumentException va fi aruncat pentru valori negative ale phacotrial. Metoda todo va fi ignorată. Încercați să eliminați adnotarea @Ignore când experimentați codul.
Metoda assertTrue verifică dacă rezultatul expresiei este corect. Unele alte metode care pot veni la îndemână sunt:
- assertEquals - rezultatul așteptat și rezultatul sunt aceleași;
- assertNull - rezultatul expresiei este null;
- assertNotNull - rezultatul expresiei este diferit de null;
- assertSame - obiectele așteptate și primite sunt același obiect.
- fail - metoda aruncă o excepție AssertionError - o adăugăm acolo unde progresul programului nu ar trebui să ajungă.
În lumea noastră modernă IDE poate găsi și pur și simplu să ruleze teste în proiect. Dar dacă doriți să le porniți manual folosind codul programului. Puteți folosi Runner pentru a face acest lucru. Există text - junit.textui.TestRunner, versiuni grafice - junit.swingui.TestRunner, junit.awtui.TestRunner.
Dar o metodă puțin mai modernă este utilizarea clasei JUnitCore. Adăugați următoarea metodă principală la clasa MathFuncTest:
Iar rezultatul este:
În versiunile anterioare ale JUnit, pentru a scrie o clasă de testare, a fost necesar să se creeze succesorul junit.framework.TestCase. Apoi a fost necesar să se definească un constructor care să ia numele metodei ca parametru String și să îl transmită clasei părinte. Fiecare metodă de testare a trebuit să înceapă cu testul prefixului. Pentru a inițializa și a elibera resursele, s-au folosit metodele setUp și tearDown. Pe scurt, oroarea. Ei bine, acum totul este simplu, da.
Vă rugăm să clarificați situația. Care este semnificația lui JUnit? De exemplu, linii
Sunt inventate, în ceea ce privește verificarea? La urma urmei, atunci când depanem o metodă, verificăm încă corectitudinea activității sale. Deci, care este sensul acestor linii atunci? Se pare că situația este artificială.
Chiar vreau să înțeleg. Vă mulțumim anticipat,
Toate testele sunt inventate în cele din urmă, testele fără minte nu sunt necesare de nimeni și de ceea ce vor testa - marele întrebare ...
Debug: pot fi diferite, totul depinde de aplicație - există momente când nu depanare manuală nu se poate face în nici un fel (pentru a colecta echipa de testeri), dar sunt momente când lucrurile simple pot fi verificate în etapa a ansamblului de aplicare - pentru acest lucru și a crea Junit-teste. Trebuie să acceptați, este mult mai plăcut atunci când o persoană efectuează o piesă de fier, dar încă mai rapid, și, de asemenea, la momentul compilarii.
În acest exemplu, se folosește o singură clasă și, în realitate, pot exista mult mai multe (și dependențe între ele) și, prin urmare, probabilitatea unei erori crește ...
Foarte rar se întâmplă că clasa este scrisă o dată pentru totdeauna, SDK și care este actualizată periodic. Aici vine necesitatea unor teste automate.