Arhitectura JUnit 5. Partea a sasea
Ultimul articol din seria noastra despre arhitectura JUnit 5. In acest ultim articol ne uitam la abordarea JUnit 5. Prin introducerea propriilor extensii JUnit 5 are functii similare cu regulile JUnit 4. Codul este mai concis si se bazeaza pe stilul adnotarilor declarative.
Jul 22, 2020 318
Articole pe aceeasi tema
Alte articole
Programarea reactiva in Java. Abordarea reactiva
Testarea software. O perspectiva economica
Programarea reactiva in Java. Reactivitate
Cum apar problemele in testarea software personalizata
Programarea reactiva in Java. CompletableFuture si Async
Programarea reactiva in Java. Data flow
Programarea reactiva in Java. Multithreading
Smart Home: Un exemplu de implementare si dezvoltare. Partea a treia
Imbunatateste-ti abilitatile cu noile cursuri de la Luxoft Training
Abordarea bazata pe prioritizarea riscurilor – Cum oferim valoare maxima intr-o perioada scurta de timp. Partea a doua
Ultimul articol din seria noastra despre arhitectura JUnit 5. In acest ultim articol ne uitam la abordarea JUnit 5. Prin introducerea propriilor extensii JUnit 5 are functii similare cu regulile JUnit 4. Codul este mai concis si se bazeaza pe stilul adnotarilor declarative. In primul rand definim clasa CustomExtension, care este folosita ca argument al adnotarii @ExtendWith pe clasa testata.
In listarea 9, facem urmatoarele lucruri:
In listarea 10, facem urmatoarele lucruri:
Cand clasa de test este extinsa cu clasa CustomExtension, metodele beforeEach si afterEach definite anterior sunt executate inainte si dupa fiecare metoda de testare.
Putem sa observam cu usurinta diferentele intre claritatea si lungimea codului la JUnit 4 in comparatie cu JUnit 5. Abordarea JUnit 4 ne obliga sa lucram cu 3 clase, in timp ce in abordarea JUnit 5 lucram doar cu 2 clase. Codul care trebuie sa fie executat inainte si dupa fiecare metoda de testare este izolat intr-o metoda dedicata cu un nume clar. Legat de clasa de testare, nu trebuie sa facem altceva decat sa o adnotam cu @ExtendWith.
JUnit 5 extension model poate sa fie folosit pentru a inlocui gradual runners din JUnit 4. Pentru extensiile care au fost deja create, procesul de migrare este simplu. Spre exemplu:
Java and Web Technologies Expert
In listarea 9, facem urmatoarele lucruri:
- Declaram CustomExtension ca implementand interfetele AfterEachCallback si BeforeEachCallback (1’).
- Trecem peste metoda afterEach, care urmeaza sa fie executata dupa fiecare metoda de testare din clasa de testare care este extinsa cu CustomExtension (2’).
- Trecem peste metoda beforeEach care urmeaza sa fie executata dupa fiecare metoda de testare din clasa de testare care este extinsa cu CustomExtension (3’).
In listarea 10, facem urmatoarele lucruri:
- Extindem JUnit5CustomExtensionTester cu clasa CustomExtension (1’).
- Extindem metoda myCustomRuleTest si o adnotam cu @Test (2).
Cand clasa de test este extinsa cu clasa CustomExtension, metodele beforeEach si afterEach definite anterior sunt executate inainte si dupa fiecare metoda de testare.
Putem sa observam cu usurinta diferentele intre claritatea si lungimea codului la JUnit 4 in comparatie cu JUnit 5. Abordarea JUnit 4 ne obliga sa lucram cu 3 clase, in timp ce in abordarea JUnit 5 lucram doar cu 2 clase. Codul care trebuie sa fie executat inainte si dupa fiecare metoda de testare este izolat intr-o metoda dedicata cu un nume clar. Legat de clasa de testare, nu trebuie sa facem altceva decat sa o adnotam cu @ExtendWith.
JUnit 5 extension model poate sa fie folosit pentru a inlocui gradual runners din JUnit 4. Pentru extensiile care au fost deja create, procesul de migrare este simplu. Spre exemplu:
- Pentru a migra testele Mockito, trebuie sa inlocuim, in clasa testata, adnotarea @RunWith(MockitoJUnitRunner.class) cu adnotarea @ExtendWith(MockitoExtension.class).
- Pentru a migra testele Spring, trebuie sa inlocuim, in clasa testata, adnotarea @RunWith(SpringJUnit4ClassRunner.class) cu adnotarea @ExtendWith(SpringExtension.class).
- In momentul scrierii acestui articol, nu exista extensie pentru testele Arquillian.
Concluzii
In cadrul acestei serii am discutat despre noua arhitectura JUnit 5 si motivul pentru care a aparut. Am evidentiat abordarea modularea a JUnit 5. De asemenea am aratat si cum sa migram codul de la JUnit 4 la JUnit 5: migrarea de la reguli la extensii, migrarea de la reguli personalizate la extensii personalizate.Vrei sa inveti mai multe despre aceasta tehnologie? Descopera cursurile noastre.
Catalin Tudose
Java and Web Technologies Expert