Gostaria de entender como funcionam os testes em java

Programação Java
, ,
#1

Aqui vai algumas dúvidas:

  • minha classe de teste ela é idependente das classes da aplicação(entities, dao, repository, service…) né? Tipo, eu só executo minha classe de teste quando eu quero saber se eles está tudo bem no meu código, né isso?

  • Digamos que eu esteja usando o spring boot, no arquivo “aplication.properties” deve colocar a configuração do banco de dados, mysql, por exemplo. Como eu faço para criar um segundo arquivo “.properties” para colocar as configurações do banco de teste(H2, por exemplo), para que quando eu rodar as classes de teste, o “.properties” de teste seja usado? Pois eu imagino que se tiver dois arquivos “.properties” não dará conflito?

#2
  1. As classes da sua aplicação são independentes das classes de teste, mas as classes de teste dependem das classes da sua aplicação.

Por exemplo, digamos que vc tenha a classe ArticleServiceTest que testa ArticleService. Quando vc executa seus testes, tanto ArticleService quanto ArticleServiceTest são compiladas.

  1. Quando vc cria seu projeto Spring Boot pelo site, vc vai ter 2 conjuntos de código fonte.

O primeiro conjunto fica em src/main/java e seu .properties fica em src/main/resources. Este é o código + configuração da sua aplicação real.

O segundo conjunto fica em src/test/java e vc pode criar seu .properties em src/test/resources/application.properties. Este é o conjunto + configuração dos seus testes.

Viu como cada conjunto tem seu próprio application.properties? É assim que funciona.

Mas se vc percisar de algo mais complexo, o Spring permite que vc crie vários perfis e tenha um .properties para cada perfil.

Vc poderia ter uma estrutura assim:

my-project
└── src
    └── main
        ├── java
        └── resources
            ├── application-dev.properties
            └── application-prod.properties

Onde application-dev.properties contém a configuração do seu banco de dados local e application-prod.properties contém configuração do banco de dados de produção.

Eu achei este vídeo que explica melhor: https://www.youtube.com/watch?v=pfuRljiI4ts

1 curtida
#3

Uma dúvida surgiu aqui com essa questão de perfil. Quando usar eles e quando usar o properties do “src/test/java”, tem diferença?

#4

Me perdoe, pois do jeito que eu descrevi parece mesmo que os perfis e o src/test/resources/application.properties são equivalentes.

Vamos esclarecer o primero ponto:

O Spring lê src/main/resources/application.properties sempre que vc executa sua aplicação normalmente, seja usando gradle bootRun ou mvn spring-boot:run.

Mas quando vc executa os seus testes, o Spring lê src/test/resources/application.properties. Se o Spring não encontrar um properties em src/test ele vai usar o que está em src/main.

Quando eu devo usar um properties em src/test?\

Quando vc precisa de configurações diferentes para os seus testes.

Aqui está um exemplo prático:

O ideal é que o seu ambiente de teste seja o mais parecido possível com o ambiente de produção, mas vamos imaginar que vc usa o MySQL enquanto está programando e usa o H2 quando roda seus testes automatizados.

Vc colocaria as configurações do MySQL em main/resources e as configurações do H2 em test/resources.

Agora o segundo ponto que é sobre os perfis.

Vc pode ter multiplos perfis em sua aplicação. Os motivos para usar multiplos perfis são inúmeros, mas aqui está um exemplo simples:

Digamos que na sua empresa vc tenha 2 ambientes:

  1. O ambiente de produção, que é o ambiente real usados pelos seus clientes

  2. O ambiente de verificação, que é um ambiente provisório para onde vc manda novas funcionalidades para que possam ser testadas antes de serem passadas para o ambiente de produção.

Com base nisso vc poderia ter estas 3 configurações:

  1. src/main/resources/application-verification.properties. Que teria os dados de acesso do MySQL do seu ambiente de verificação.

  2. src/main/resources/application-production.properties. Que teria os dados de acesso do MySQL do seu ambiente de produção.

  3. src/main/resources/application-dev.properties. Que teria os dados de acesso do MySQL que vc instalou na sua própria máquina, é o que vc usa enquanto está desenvolvendo.

Perceba que tanto o ambiente de produção quanto o de verificação, de acordo com meu exemplo, são servidores reais que poderiam ser acessados pela Internet. A diferença é que o endereço do ambiente de produção é conhecido e acessado pelos seus clientes, já o endereço do ambiente de verificação é secreto, conhecido apenas por vc e pelo time responsável por aprovar as novas funcionalidades.

1 curtida