Testes avançados com Mockito

1.1 biblioteca Mockito

Hoje vamos nos familiarizar com testes avançados. Mais especificamente, com a biblioteca Mockito . Nem pense em sair desse negócio.

Em primeiro lugar, esta biblioteca é um padrão no teste do Spring . Que é realmente o padrão na indústria de desenvolvimento de back-end Java.

Em segundo lugar, você terá que escrever testes para seu código Spring . A única maneira de entender que o back-end que você escreveu funciona como deveria é chamar os métodos de sua API . E fazer isso com testes é 10 vezes mais fácil do que sem eles. Você verá por si mesmo.

Você pode adicionar a biblioteca Mockito à sua pom.xmlusando o código:

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

Todo o código-fonte do projeto Mockito pode ser encontrado no GitHub .

1.2 Objetos simulados

Então, o que é esse Mockito e por que é tão bom?

No processo de desenvolvimento e desenvolvimento de testes, muitas vezes havia a necessidade de inserir algum tipo de "esboço" no código em vez de um objeto real.

Por exemplo, o código que funciona com o banco de dados é testado e muda alguma coisa ali. É bom que antes de cada teste o estado desse banco de dados seja o mesmo (caso contrário os testes serão diferentes). E eu gostaria que a base fosse mais simples para reverter rapidamente esses estados.

Ou, por exemplo, você está testando um código que envia SMS úteis. E para mala direta, ele usa algum tipo de gateway de SMS pago. Seria bom colocar algum Gateway virtual nele para testar o código, para não enviar centenas de SMS para pessoas incompreensíveis.

Ou seu código está solicitando dados de outros servidores web que simplesmente não estão disponíveis no servidor de teste. Ou você escreve um código para pagamentos online que precisa ser testado 50 vezes e só então pode ser usado em canais financeiros reais.

Acho que você entendeu ... Objetos virtuais, ou como também são chamados de objetos stub, são uma coisa muito útil.

E aqui vem a dificuldade - Java tem tipagem estática. Isso significa que para ReadDatabaseatribuir uma referência a um objeto a uma variável em vez de um objeto do tipo VirtualDatabase, você precisa herdar a classe VirtualDatabasede RealDatabase.

Acontece que a classe tem RealDatabasevários métodos privados e variáveis ​​que armazenam referências a outros objetos reais, e você não pode escrever um stub normal dessa maneira. Na teoria é bom, mas na prática é um beco sem saída.

E aqui vem o resgate ( você pode lerDynamicProxy com mais detalhes ), que apareceu no Java 5. Ele permite que você crie objetos virtuais dos quais o compilador não reclama.

Esses objetos virtuais são chamados de mocks (da palavra mock - layout). A biblioteca Mockito conseguiu levar o trabalho com esses mocks a uma altura sem precedentes. Daí, aliás, o nome da biblioteca.

1.3 Anotação @ExtendWith

A biblioteca Mockito funciona muito bem com JUnit, podendo até ser considerada uma extensão dela.

Existem duas maneiras de habilitar a biblioteca Mockito em seus testes de unidade. A primeira maneira é adicionar uma anotação especial:

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

A segunda maneira é habilitar seu trabalho chamando o método openMocks():

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

Na maioria das vezes, você verá a primeira opção, mas às vezes é útil saber que existe uma segunda.