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 173
Articole pe aceeasi tema
Alte articole
Test Driven Development cu JUnit 5. Partea a sasea
Test Driven Development cu JUnit 5. Partea a cincea
Test Driven Development cu JUnit 5. Partea a patra
Test Driven Development cu JUnit 5. Partea a treia
Test Driven Development cu JUnit 5. Partea a doua.
Cum sa te pregatesti pentru certificarile IIBA. Provocari si solutii
Test Driven Development cu JUnit 5
Testarea aplicatiilor cu JUnit 5 si Mockito. Partea doua
Testarea aplicatiilor cu JUnit 5 si Mockito. Prima parte
Testarea aplicatiilor cu JUnit5 si JMock 2. 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