Test avanzati con Mockito

1.1 Libreria Mockito

Oggi faremo conoscenza con i test avanzati. Più specificamente, con la libreria Mockito . Non pensare nemmeno di uscire da questa faccenda.

Innanzitutto, questa libreria è uno standard nei test di primavera . Che in realtà è lo standard nel settore dello sviluppo back-end Java.

In secondo luogo, dovrai scrivere test per il tuo codice Spring . L'unico modo per capire che il backend che hai scritto funziona come dovrebbe è chiamare i metodi della sua API . E farlo con i test è 10 volte più facile che senza. Vedrai di persona.

Puoi aggiungere la libreria Mockito alla tua pom.xmlusando il codice:

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

L'intero codice sorgente per il progetto Mockito può essere trovato su GitHub .

1.2 Oggetti fittizi

Allora cos'è questo Mockito e perché è così buono?

Nel processo di sviluppo e sviluppo dei test, molto spesso era necessario inserire nel codice una sorta di "stub" invece di un oggetto reale.

Ad esempio, il codice che funziona con il database viene testato e cambia qualcosa lì. È bene che prima di ogni test lo stato di questo database sia lo stesso (altrimenti i test saranno diversi). E vorrei che la base fosse più semplice per ripristinare rapidamente questi stati.

Oppure, ad esempio, stai testando un codice che invia SMS utili. E per il direct mailing usa una sorta di gateway SMS a pagamento. Sarebbe bello infilarci dentro qualche Gateway virtuale per testare il codice, in modo da non inviare centinaia di SMS a persone incomprensibili.

Oppure il tuo codice sta richiedendo dati da altri server Web che semplicemente non sono disponibili sul server di test. Oppure scrivi un codice per i pagamenti online che deve essere testato 50 volte e solo allora consentito per essere utilizzato in canali finanziari reali.

Penso che tu capisca ... Gli oggetti virtuali, o come vengono anche chiamati oggetti stub, sono una cosa molto utile.

E qui arriva la difficoltà: Java ha una tipizzazione statica. Ciò significa che per ReadDatabaseassegnare un riferimento a un oggetto a una variabile anziché a un oggetto di tipo VirtualDatabase, è necessario ereditare la classe VirtualDatabaseda RealDatabase.

Quindi si scopre che la classe ha RealDatabaseuna serie di metodi e variabili privati ​​che memorizzano riferimenti ad altri oggetti reali e non è possibile scrivere uno stub normale in questo modo. In teoria va bene, ma in pratica è un vicolo cieco.

E qui viene in soccorso ( puoi leggereDynamicProxy più in dettaglio ), che è apparso in Java 5. Ti permette di creare oggetti virtuali di cui il compilatore non si lamenta.

Tali oggetti virtuali sono chiamati mock (dalla parola mock - layout). La biblioteca Mockito è stata in grado di portare il lavoro con questi mock a un'altezza senza precedenti. Da qui, a proposito, il nome della biblioteca.

1.3 Annotazione @ExtendWith

La libreria Mockito funziona alla grande con JUnit, può anche essere considerata un'estensione di essa.

Esistono due modi per abilitare la libreria Mockito nei test unitari. Il primo modo è aggiungere un'annotazione speciale:

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

Il secondo modo è abilitare il suo lavoro chiamando il metodo openMocks():

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

Molto spesso vedrai la prima opzione, ma a volte è utile sapere che ce n'è una seconda.