100 Dias de código: Meu log diário!

devmpoda

Matheus Poda

Posted on August 14, 2023

100 Dias de código: Meu log diário!

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:

  1. Programe/Estude 1 hora por dia (pelo menos);
  2. Tweete todos os dias o seu aprendizado com a hashtag #100DiasDeCodigo;
  3. 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>
Enter fullscreen mode Exit fullscreen mode

-> 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);
                });

    }
}

Enter fullscreen mode Exit fullscreen mode

-> 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:

  1. 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");
    }

Enter fullscreen mode Exit fullscreen mode
  1. 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);
        }
    }
Enter fullscreen mode Exit fullscreen mode
  • 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:
💖 💪 🙅 🚩
devmpoda
Matheus Poda

Posted on August 14, 2023

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related

100 Dias de código: Meu log diário!
braziliandevs 100 Dias de código: Meu log diário!

August 14, 2023