Introdução
A ideia do 100 Dias de código, é te ajudar a criar o hábito de estudar, pelo menos 1 horinha por dia e ir compartilhando seu progresso publicamente.
Site brasileiro: https://www.100diasdecodigo.dev/
Quais são as regras:
- Programe/Estude 1 hora por dia (pelo menos);
- Tweete todos os dias o seu aprendizado com a hashtag #100DiasDeCodigo;
- Entre em contato, pelo menos 2 pessoas por dia, para conversar sobre o estudo!
Meu objetivo
Esse artigo vai ser um log diário, onde vou atualizar tanto no meu twitter, quanto neste artigo, meus estudos durante esses 100 dias!
Quais assuntos que estarei estudando: Java e Arquitetura de Software, me comprometo a me aperfeiçoar em Java e continuar meus estudos de arquitetura de software, que inclusive você pode acompanhar meus artigos sobre aqui!
Aguardo vocês interagindo comigo e outros estudiosos 💪🔥
LOG DE ESTUDOS
Agosto/23
Dia 1: 15 de Agosto. Terça
- Tema do estudo: Teste de integração no Spring
- Detalhes: Aprendi como desenvolver testes de integração no Spring.
-> Teste de integração
É uma das formas de teste automatizado, muito parecido com o teste unitário, porém aqui o foco é realizar o teste das integrações dos componentes do software, logo não mockamos as dependências e conexões. Como resultado, é bem mais lento do que testes unitários.
-> Configuração de projeto Spring
O Spring Boot, possui dois starters para nos ajudar a trabalhar com testes, o starter-test e o starter-validation, tendo eles, podemos começar a trabalhar como de costume utilizando a anotação própria do Spring em nossas classes de teste e também o bom e velho JUnit.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
-> Primeiros testes de integração
Os primeiros testes foram bem simples, estou utilizando em uma API que possui um CRUD completo de cozinhas e restaurantes, estilo IFood. Então fiz da seguinte forma:
@SpringBootTest
class CadastroCozinhaIntegrationTest {
@Autowired
private CadastroCozinhaService cadastroCozinhaService;
@Test
public void deveCadastroCozinhaComSucesso_QuandoCozinhaCorreta() {
//cenário
Cozinha novaCozinha = new Cozinha();
novaCozinha.setNome("Chinesa");
//ação
novaCozinha = cadastroCozinhaService.salvar(novaCozinha);
//validação
assertThat(novaCozinha).isNotNull();
assertThat(novaCozinha.getId()).isNotNull();
}
@Test()
public void deveFalharAoCadastrarCozinha_QuandoSemNome() {
//cenário
Cozinha novaCozinha = new Cozinha();
novaCozinha.setNome(null);
ConstraintViolationException erroEsperado =
Assertions.assertThrows(ConstraintViolationException.class, () ->{
cadastroCozinhaService.salvar(novaCozinha);
});
}
}
-> GivenWhenThen do BDD
Estou tentando aprimorar a forma como escrevo testes utilizando o padrão GivenWhenThen, onde primeiro montamos o cenário do teste, depois a condição e por fim a execução do teste.
Para mais detalhes desse padrão, tem esse artigo do Martin Fowler muito bom: https://martinfowler.com/bliki/GivenWhenThen.html
-> Maven Failsafe plugin
Quando temos testes de integração em nosso projeto, não é uma boa ideia executarmos eles todas as vezes que vamos buildar nosso projeto, por conta disso aprendi que existe esse plugin do maven, que consegue enxergar classes com o sufixo 'IT'.
Com ele conseguimos evitar a execução dos testes de integração no processo de building.
- Pensamentos: Estou ansioso por esse desafio, tenho um pouco de receio de acabar não finalizando ele, mas o que importa é tentar!
Dia 2: 17 de Agosto. Quinta
- Tema do estudo: Testes unitários com JUnit
- Detalhes:
Continuando meus estudos de testes automatizados, voltei para dar um pouco de atenção aos testes unitários, o que eu aprendi nesse dia foi:
- Ciclo de vida do JUnit
Por padrão, o código de teste cria uma nova instância do objeto que será testado, a cada teste.
Podemos resolver isso entendendo como podemos brincar com o ciclo de vida dos testes, para isso o JUnit nos proporciona 4 anotações:
- @BeforeAll => Executado antes de rodar todos os testes;
- @AfterAll => Executado depois de rodar todos os testes;
- @BeforeEach => Executado antes de rodar cada teste;
- @AfterEach => Executado antes de rodar cada teste.
Esse conceito é muito importante, principalmente nos testes de integração, por exemplo, usar o @BeforeAll para inicializar uma conexão com a base de dados e depois o @AfterAll para finalizar a conexão.
Exemplo de código:
private SimpleMath math;
@BeforeAll
static void setup(){
System.out.println("Running @BeforeAll method!");
}
@AfterAll
static void cleanup(){
System.out.println("Running @AfterAll method!");
}
@BeforeEach
void beforeEachMethod(){
math = new SimpleMath();
}
@AfterEach
void afterEachMethod(){
System.out.println("Running @AfterEach");
}
- Como testar performance com o JUnit
Para fazer isso temos a anotação @Timeout(), que podemos informar o tempo limite que aquele determinado algoritmo vai terminar, para passar no teste.
Fiz um exemplo, onde podemos passar por padrão segundos, mas também podemos específicar para ms.
No exemplo, estou usando um for para realmente demorar e não passar o teste, afim de experimento mesmo:
@Test
//@Timeout(1)
@Timeout(value = 15, unit= TimeUnit.MILLISECONDS)
void testPerformance(){
int [] numbers = {25, 8, 21, 32, 3};
for (int i=0; i<1000000;i++){
numbers[0] = i;
Arrays.sort(numbers);
}
}
- Pensamentos: Acabei não conseguindo estudar ontem por causa de alguns probleminhas pessoais que tive que resolver, mas aqui deixo a ideia do "não errar duas vezes", tudo bem não estudar um dia, mas nunca deixe virar dois dias seguidos!
Dia 3: 18 de Agosto. Sexta
- Tema do estudo:
- Detalhes:
- Pensamentos:
Top comments (0)