Arhitectura JUnit 5. Partea a patra

Cel de-al patrulea articol din seria despre arhitectura JUnit 5. Continuam discutia noastra despre reguli versus extension model si ne uitam la noua abordare JUnit 5.

Jul 2, 2020 69

JUnit5ExceptionTester class.JPG


In cadrul acestui exemplu JUnit 5, facem urmatoarele lucruri:

  1. Initializam o instanta a clasei Calculator a carei functionalitate o testam (1’)
  2. Presupunem ca executia executabilului calculator.sqrt(-1) genereaza o IllegalArgumentException (2’)
  3. Presupunem faptul ca executia calculator.divide(1, 0) genereaza o ArithmeticException (3’)

Este de remarcat diferenta clara in ceea ce priveste claritatea si lungimea codului intre JUnit 4 si JUnit 5. Codul de testare efectiv la JUnit 5 este de 13 linii, in timp ce la JUnit 4 avem 20 de linii. Nu trebuie sa initializam sau sa ne ocupam de alte reguli aditionale. Metodele de testare JUnit 5 contin o linie fiecare.

O alta regula pe care am vrea sa o migram este TemporaryFolder. Regula TemporaryFolder permite crearea de fisiere si foldere care ar trebui sa fie sterse cand metoda de test se incheie (indiferent daca rezultatul este pozitiv sau negativ). Regula JUnit 4 a fost inlocuita cu adnotarea @TempDir in JUnit 5. In cadrul figurii 4 aratam abordarea JUnit 4.

JUnit4RuleTester class.JPG



In cadrul acestui exemplu facem urmatoarele lucruri:

  1. Declaram un camp temporar TemporaryFolder adnotat cu @Rule si il initializam. Adnotarea @Rule trebuie sa fie aplicata fie pe un camp public, fie pe o metoda publica
  2. Folosim campul TemporaryFolder pentru a crea un fisier si folder (2) Acestea se vor gasi in folderul Temp al profilului tau de utilizator din cadrul sistemului de operare.
  3. Verificam existenta folderului si fisierului temporar

Acum ne mutam atentia la noua abordare JUnit 5 (fig 5).

JUnit5TempDirTester class.JPG



In cadrul exemplului anterior JUnit 5, facem urmatoarele lucruri:

  1. Declaram un camp adnotat @TempDir (1’)
  2. Verificam crearea acestui director temporar inainte de a executa testul (2’)
  3. Cream un fisier in acest director si verificam daca exista (3’)

Avantajul abordarii JUnit 5 este ca nu trebuie sa cream folderul de unii singuri prin intermediul unui constructor. Acesta este automat creat o data ce adnotam campul cu @TempDir.

Mergem mai departe la inlocuirea unei reguli personalizate. Propriile reguli sunt foarte utile cand anumite tipuri de teste au nevoie de actiuni aditionale similare inainte si dupa executie.

In JUnit 4 avem nevoie ca actiunile noastre aditionale sa fie executate inainte si dupa executia unui test. In consecinta, am putea sa cream propriile noastre clase care implementeaza interfata TestRule. Pentru a face asta, trebuie sa intrerupem actiunea metodei apply(Statement, Description) care genereaza o instanta a Statement. Un asemenea obiect reprezinta testele din cadrul JUnit runtime si le aplica Statement#evaluate()runs. Obiectul Description descrie testul individual. Il putem folosi pentru a citi informatii despre test prin reflectie.

CustomRule class.JPG


Pentru a arata in mod clar cum sa ne definim propriile reguli, ne uitam la figura 6, unde facem urmatoarele lucruri:

  1. Declaram clasa noastra CustomRule care implementeaza interfata TestRule (1)
  2. Mentinem referintele in cadrul unui camp Statement si adaugam un camp Descriere (2) si le folosim pentru a aplica metoda care genereaza CustomStament (3)


Vrei sa inveti mai multe despre aceasta tehnologie? Descopera cursurile noastre.

Catalin Tudose
Java and Web Technologies Expert

Daca iti place acest articol, distribuie-l si prietenilor tai!




Luxoft Warsaw - Warsaw Spire, plac Europejski 1, 00-844 Warszawa
Dimitrie Pompeiu nr 5-7 , building C, Et. 5, sect 2, Bucharest, 014459

Contact phone:

021 371 4858
Luxoft Poland Wroclaw - Silver Tower pl. Konstytucji 3-go Maja 3 50-048 Wroclaw
Aleja Generała Tadeusza Bora-Komorowskiego 25, Quattro Business Park Five, 31-476 Kraków, Poland

Contact phone:

+48 122110650
Success
Iti multumim.
Inregistrarea ta a fost trimisa.