Testare avansată cu Mockito

1.1 Biblioteca Mockito

Astăzi ne vom familiariza cu testarea avansată. Mai precis, cu biblioteca Mockito . Nici să nu te gândești să ieși din afacerea asta.

În primul rând, această bibliotecă este un standard în testarea Spring . Care este de fapt standardul în industria de dezvoltare backend Java.

În al doilea rând, va trebui să scrieți teste pentru codul Spring . Singura modalitate de a înțelege că backend-ul pe care l-ați scris funcționează așa cum ar trebui este să apelați metode ale API-ului său . Și să o faci cu teste este de 10 ori mai ușor decât fără ele. Vei vedea singur.

Puteți adăuga biblioteca Mockito la a dvs. pom.xmlfolosind codul:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

Întregul cod sursă pentru proiectul Mockito poate fi găsit pe GitHub .

1.2 Obiecte simulate

Deci, ce este acest Mockito și de ce este atât de bun?

În procesul de dezvoltare și dezvoltare a testării, de foarte multe ori a fost nevoie de a introduce un fel de „ciot” în cod în loc de un obiect real.

De exemplu, codul care funcționează cu baza de date este testat și modifică ceva acolo. Este bine ca inainte de fiecare test starea acestei baze de date sa fie aceeasi (in caz contrar testele vor fi diferite). Și mi-aș dori ca baza să fie mai simplă pentru a retrage rapid aceste stări.

Sau, de exemplu, testați un cod care trimite SMS-uri utile. Și pentru corespondența directă, el folosește un fel de SMS Gateway plătit. Ar fi bine să strecurați niște Gateway virtual în el pentru a testa codul, pentru a nu trimite sute de SMS-uri unor persoane de neînțeles.

Sau codul dvs. solicită date de la alte servere web care pur și simplu nu sunt disponibile pe serverul de testare. Sau scrieți un cod pentru plăți online care trebuie testat de 50 de ori și abia apoi permis să fie folosit în canalele financiare reale.

Cred că înțelegi... Obiectele virtuale, sau cum se mai numesc și obiecte stub, sunt un lucru foarte util.

Și aici vine dificultatea - Java are tastare statică. Aceasta înseamnă că pentru a ReadDatabaseatribui o referință la un obiect unei variabile în loc de un obiect de tip VirtualDatabase, trebuie să moșteniți clasa VirtualDatabasede la RealDatabase.

Apoi, se dovedește că clasa are RealDatabaseo grămadă de metode și variabile private care stochează referințe la alte obiecte reale și nu puteți scrie un stub normal în acest fel. În teorie este bine, dar în practică este o fundătură.

Și aici vine în ajutor ( puteți citiDynamicProxy mai detaliat ), care a apărut din nou în Java 5. Vă permite să creați obiecte virtuale despre care compilatorul nu are nicio plângere.

Astfel de obiecte virtuale sunt numite mock-uri (din cuvântul mock - layout). Biblioteca Mockito a reușit să ducă lucrările cu aceste imitații la o înălțime fără precedent. De aici, apropo, numele bibliotecii.

1.3 @ExtendWith adnotare

Biblioteca Mockito funcționează excelent cu JUnit, poate fi considerată chiar o extensie a acesteia.

Există două moduri de a activa biblioteca Mockito în testele dvs. unitare. Prima modalitate este să adăugați o adnotare specială:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

A doua modalitate este de a-i activa funcționarea apelând metoda openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Cel mai adesea, veți vedea prima opțiune, dar uneori este util să știți că există o a doua.