Nivel de intrare al testului java online. Testarea programului, JUnit. Cerințe preliminare pentru testarea Java

Cred că dezvoltarea de software este mai mult decât o muncă. Mă văd ca un meșter care încearcă să devină mai bun în fiecare zi. Cel mai „ușor” mod de a face acest lucru este să găsești câteva instrumente bune și să răspunzi la următoarele întrebări:

  • Când ar trebui să folosesc Tool X?
  • Cum ar trebui să folosesc instrumentul X?

Testarea automată este o parte foarte importantă a dezvoltării software, dar există puține postări pe blogurile programatorilor despre instrumentele utilizate. Același articol vă va permite să vă uitați în „cutia mea de instrumente”. Voi acoperi 12 biblioteci și cadre pe care le folosesc pentru a scrie teste de unitate și de integrare și voi oferi link-uri către pagini care vă vor ajuta să înțelegeți cum să le utilizați.

Să ne uităm în cutia mea de instrumente

Înainte de a putea folosi instrumentele descrise mai jos, trebuie să configurați o versiune care rulează automat integrarea și testele unitare. Am 2 note pe acest subiect:

  • Testarea de integrare cu Maven descrie modul în care putem configura o versiune Maven cu integrare și teste unitare în diferite directoare.
  • Noțiuni introductive cu Gradle: Testarea de integrare cu Pluginul TestSets acoperă același lucru pentru Gradle.

Acum ești gata să arunci o privire mai atentă la instrumentele mele. Le-am împărțit în categorii pentru a vă facilita navigarea.

Deci, iată 12 instrumente pe care le folosesc pentru integrare și testare unitară.

Executarea testelor

AssertJ oferă un API flexibil pentru scrierea aserțiunilor cu mesaje de eroare utile, îmbunătățește lizibilitatea codului de testare și vă permite să transformați testele în specificații executabile care aderă la limbajul dorit specific domeniului.

În plus:

  • Utilizarea Hamcrest în testare acoperă modul de utilizare a Hamcrest pentru a scrie teste, precum și cum să-și extindă capacitățile cu module personalizate.
  • Transformarea aserțiilor într-un limbaj specific domeniului explică cum să creați aserțiuni personalizate în AssertJ.
  • Scrierea de teste curate: Înlocuirea aserțiilor cu un limbaj specific domeniului. Explică de ce ar trebui să înlocuim afirmațiile standard ale JUnit cu ale noastre care folosesc limbajul adecvat specific domeniului.

Testarea codului de acces la date

Baza de date rapidă, utilă pentru scrierea testelor de integrare care rulează mașină locală dezvoltator.

O extensie la JUnit care poate fi folosită pentru a inițializa baza de date la o stare cunoscută înainte de a rula fiecare test de integrare și pentru a popula baza de date cu datele necesare. DbUnit are dezavantajele sale, dar este foarte unealtă folositoare, care vă permite să separați datele de testare și codul de testare.

În plus:

  • descrie componentele cheie ale DbUnit pe care trebuie să le cunoașteți pentru a scrie teste folosind DbUnit.
  • oferă cinci reguli pentru scrierea celor mai bune teste pentru codul de acces la date.

În timp ce căutam sarcini de testare pentru programatorii Java, am dat peste un site interesant (utilizatorii Avast nu ar trebui să meargă, este detectat un troian de script, altele aparent sunt în regulă) - http://www.betterprogrammer.com. Testează calificările programatorilor Java în cel mai simplu mod, dar într-un mod automat: oferind să scrieți mai multe funcții (metode) de complexitate crescândă și să copiați codul în TextArea. În continuare, motorul site-ului face ceva cu sarcinile (nu mai puțin decât un test unitar), calculează un anumit indice de calificare pe baza criteriilor „viteză-calitate” și dă scorul final în următoarea formă:

Apoi încep întrebările. Eu însumi am programat în Java pentru a doua oară în viață (și, prin urmare, pur și simplu am omis sarcini complexe), așa că 82% din acest test corespund nivelului programator non-java. Cât de mult ar trebui să recruteze Java Junior, Java Programmer și cu atât mai mult Java Senior?! De la ce rezultat te poți aștepta prezent programator java - 90, 95, 99? Și, în sfârșit, ce se întâmplă dacă „programatorul” obține un scor mai mic de 82, dar totuși aplică pentru un fel de job?!

Testarea nu este întotdeauna distractivă și interesantă. Acest proces este de obicei destul de lung și uneori plin de muncă monotonă. Se pare că recent programatorii au folosit ieșirea standard sau un depanator pentru a testa clasele java.

În acest articol voi descrie biblioteca JUnit 4, care simplifică și automatizează foarte mult procesul de scriere a testelor.

Pentru a demonstra principalele capabilități ale cadrului JUnit, să scriem o clasă primitivă în Java și să o batem joc. Această clasă va avea două metode - găsirea factorialului unui număr nenegativ și a sumei a două numere. În plus, instanța clasei va conține un contor de apeluri de metodă.

Clasa publică MathFunc ( apeluri int; public int getCalls() ( returnează apeluri; ) public long factorial (număr int) ( apeluri++; if (număr 1) ( pentru (int i = 1; i)

Acum să scriem teste unitare. Pentru a face acest lucru, vom crea o clasă cu o serie de metode de testare. Desigur, o clasă poate conține și metode auxiliare obișnuite. Pentru ca testatorul să determine cine este cine, metodele de testare trebuie adnotate cu @Test.

O adnotare poate avea următorii parametri:

  • așteptat - indicați ce excepție va fi generată de metodă (vezi exemplul de mai jos);
  • timeout - după ce timp în milisecunde testul se va opri și îl va considera nereușit.

Dacă doriți să indicați că un anumit test ar trebui să fie omis, marcați-l cu adnotarea @Ignore. Deși puteți elimina pur și simplu adnotarea @Test.

Pot exista momente când aveți nevoie de un anumit context, cum ar fi instanțe de clasă pre-create, pentru a rula fiecare caz de testare. Și după execuție, trebuie să eliberați resursele rezervate. În acest caz, veți avea nevoie de adnotări @Before și @After. Metoda marcată @Before va fi executată înainte de fiecare caz de testare, iar metoda marcată @After va fi executată după fiecare caz de testare.

Dacă inițializarea și eliberarea resurselor trebuie făcute o singură dată - respectiv, î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 scripturi de testare:

Clasa publică MathFuncTest ( matematică MathFunc privată; @Before public void init() ( math = new MathFunc(); ) @After public void tearDown() ( math = null; ) @Test public void calls() ( assertEquals(0, math) .getCalls()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math.getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignora @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )

Metoda apelurilor testează validitatea contorului de apeluri. Metoda factorială verifică dacă factorialul este calculat corect pentru unele valori standard. Metoda factorialNegative verifică dacă va fi lansată o excepție IllegalArgumentException pentru valori factoriale negative. Metoda todo va fi ignorată. Încercați să eliminați adnotarea @Ignore când experimentați cu codul.

Metoda assertTrue verifică dacă rezultatul unei expresii este adevărat. Alte metode care pot fi utile:

  • assertEquals - rezultatul așteptat și rezultatul primit se potrivesc;
  • assertNull - rezultatul expresiei este nul;
  • assertNotNull - rezultatul expresiei este diferit de null;
  • assertSame - obiectele așteptate și primite sunt același obiect.
  • fail - metoda generează o excepție AssertionError - o adăugăm acolo unde execuția programului nu ar trebui să meargă.

În a noastră lumea modernă IDE-urile pot găsi și pur și simplu rula teste într-un proiect. Dar ce se întâmplă dacă doriți să le executați manual folosind codul programului. Pentru a face acest lucru, puteți folosi Runner. Există versiuni text - junit.textui.TestRunner, versiuni grafice - junit.swingui.TestRunner, junit.awtui.TestRunner.

Dar un pic mai mult metoda modernă este utilizarea clasei JUnitCore. Adăugați următoarea metodă principală la clasa MathFuncTest:

Public static void main(String args) aruncă o excepție ( JUnitCore runner = new JUnitCore(); Rezultat rezultat = runner.run(MathFuncTest.class); System.out.println("run tests: " + result.getRunCount()); System.out.println("teste eșuate: " + result.getFailureCount()); System.out.println ("teste ignorate: " + result.getIgnoreCount()); System.out.println("succes: " + rezultat .a avut succes()); )

Și rezultatul execuției:

Executați teste: 3 teste eșuate: 0 teste ignorate: 1 succes: adevărat

În mai mult versiuni anterioare Pentru a scrie o clasă de testare JUnit, a fost necesar să se creeze un descendent al lui junit.framework.TestCase. Apoi a fost necesar să se definească un constructor care să ia ca parametru un String - numele metodei - și să-l transmită clasei părinte. Fiecare metodă de testare trebuia să înceapă cu testul prefixului. Metodele setUp și tearDown au fost folosite pentru a inițializa și a elibera resurse. Pe scurt, groază. Ei bine, acum totul este simplu, da.

Asta e tot pentru azi. Sunt sigur că JUnit Framework vă va ajuta foarte mult. Comentariile și întrebările despre articol sunt binevenite.




Top