DEV Community: João Paulo Oliveira

Testes de integreção X Testes de unidade: um confronto desigual

João Paulo Oliveira — Thu, 24 Oct 2024 04:06:41 +0000

Testes de integração é uma etapa essencial dos testes de software em que determina se módulos desenvolvidos apartados funcionarão corretamente quando executados em conjunto. Sucede aos testes de unidades que tem por objetivo validar módulos individualmente.

Seu objetivo é constatar que a integração com demais módulos de uma aplicação atende os requisitos esperados a fim de encontrar falhas nessa comunicação e mitigar possíveis erros que ocorreriam no ambiente produtivo.

Imagine uma aplicação que armazena dados em um banco, envia mensagens a um broker de mensageria e faz solicitações na rede para algum serviço.

Nos testes de integração é preciso validar se a comunicação com esses componentes foram bem sucedidas, se ao solicitar a persistência de uma informação a um banco de dados ocorreu com sucesso, se ao enviar mensagens para um broker de mensageria, por exemplo Kafka, foi entregue ou até mesmo saber como a aplicação irá se comportar fazendo requisições na rede. E claro, não somente isso, mas também assegurar que a lógica empregada no serviço foi realizada conforme o esperado!

Note, nos testes de integração é validado o comportamento da aplicação juntamente aos módulos integrados, seja ele um comportamento esperado ou não, mas somente assim para sabermos o quão nossas aplicações estão aptas para rodar em ambiente produtivo com mais segurança.

Vamos a um caso de uso:

@RestController
@RequestMapping("/api")
class ObterPedidoController(
    private val pedidoRepostiory: PedidoRepostiory,
    private val notificacao: Notificacao
) {

    @GetMapping("/pedidos/{pedidoId}/usuarios/{usuarioId}")
    fun obterPedido(
        @PathVariable usuarioId: Long,
        @PathVariable pedidoId: Long
    ): ResponseEntity<Any> {

        val pedido =  pedidoRepostiory
            .findByIdAndUsuarioId(pedidoId, usuarioId)
            .getOrElse {
                return ResponseEntity.status(404).body("Pedido nao encontrado")
            }

        try {
            notificacao.enviar(pedido)
        } catch (ex: Exception) {
            println(ex.stackTrace)
            return ResponseEntity.internalServerError().build()
        }

        val response = PedidoResponse.criar(pedido)

        return ResponseEntity.ok(response)
    }
}

Conseguimos extrair algumas informações importantes do código acima:

1 - É uma API REST que tem somente a função de obter pedido.

2 - A classe PedidoRepostiory é um ponto de interação com um banco de dados.

3 - A classe Notificacao é um de um ponto de interação para envios de mensagens.

4 - É realizado uma busca à base de dados e caso não encontrado é lançada uma exceção.

5 - É realizado o envio de uma mensagem para um serviço de Notificação.

6 - Retorna o pedido encontrado ao solicitante.

Perceba que não há regras de negócio extensas, não há validações em excesso, não há diversas lógica e caminhos, somente busca um pedido na base, envia notificação e retorna pedido, simples. Mas, se mal testado pode vir a ser problemático.

A pergunta que devemos fazer é: como testamos esse código?

Vamos começar pelo o teste de unidade:

@ExtendWith(MockitoExtension::class)
class ObterPedidoControllerUnitTest {

    @Mock
    private lateinit var pedidoRepostiory: PedidoRepostiory

    @Mock
    private lateinit var notificacao: Notificacao

    @InjectMocks
    private lateinit var controllerTest: ObterPedidoController

    @Test
    @DisplayName("Deve retonar um pedido e deve enviar uma notifição")
    fun t1() {
        // cenario
        val usuario = criaUsuario().apply { id = 1L }
        val pedido = criaPedido(usuario).apply { id = 1L }
        val pedidoResponse = PedidoResponse.criar(pedido)

        `when`(pedidoRepostiory.findByIdAndUsuarioId(pedido.id!!, usuario.id!!)).thenReturn(Optional.of(pedido))

        // acao
        val response = controllerTest.obterPedido(pedido.id!!, usuario.id!!)

        // validar
        assertThat(response.statusCode).isEqualTo(HttpStatus.OK)
        assertThat(response.body).isEqualTo(pedidoResponse)
        verify(notificacao, times(1)).enviar(pedido)
    }
}

Ao analisar esse testes temos alguns problemas:

O teste realizado acima utiliza a técnica de “mockar” o comportamento de alguns objetos ficando a cargo do desenvolvedor decidir ao mesmo como ele deve se comportar e também o que retornar.

Testes de unidade não executam o contexto de uma aplicação Spring, e neste caso existe uma interação com o banco de dados que se porventura a consulta estiver errada não saberemos e teremos um falso positivo do teste.

Como o teste é executado de maneira isolada e sem considerar o ambiente ao seu redor nunca saberemos se a comunicação com um broker de mensagem ocorreu com sucesso, se ele está aceitando as mensagens. Ou melhor, não saberemos como a aplicação irá se comportar caso as dependências externas estejam indisponíveis.

Ou seja, neste caso específico temos um teste que não testa NADA!

Vamos mudar a abordagem e olharmos para um teste de integração:

@SpringBootTest
@ActiveProfiles("test")
@AutoConfigureMockMvc
@Import(ConfiguracaoKafkaTest::class)
@DirtiesContext(methodMode = BEFORE_METHOD)
class ObterPedidoControllerTest : TestBased() {

    @Autowired
    private lateinit var mockMvc: MockMvc

    @Autowired
    private lateinit var pedidoRepostiory: PedidoRepostiory

    @Autowired
    private lateinit var usuarioRepostiory: UsuarioRepostiory

    @Autowired
    lateinit var consumer: Consumer<String, String>

    @BeforeEach
    fun beforeEach() {
        val usuario = criaUsuario()
        usuarioRepostiory.saveAndFlush(usuario)

        val pedido = criaPedido(usuario)
        pedidoRepostiory.saveAndFlush(pedido)
    }

    @AfterEach
    fun afterEach() {
        pedidoRepostiory.deleteAll()
        usuarioRepostiory.deleteAll()
    }

    @Test
    @DisplayName("Deve retonar um pedido e deve enviar uma mensagem ao topic do kafka")
    fun t1() {
        // cenario
        val request = get("/api/pedidos/1/usuarios/1")

        // acao
        val response = mockMvc.perform(request)

        // consome as mensagens
        val records = KafkaTestUtils.getRecords(consumer, Duration.ofSeconds(2))

        // validar
        response.andExpectAll(
            status().isOk,
            jsonPath("$.nomeItem").value("Feijao tropeiro"),
            jsonPath("$.quantidade").value(5)
        )
        assertThat(records).hasSize(1)
    }

    private fun criaUsuario() = Usuario("Maria", "das Dores", "maria@dores.com")
    private fun criaPedido(usuario: Usuario) = Pedido("Feijao tropeiro", 5, usuario)
}

A primeira coisa que notamos é que o teste de integração é mais complexo para escrever e isso é um fato.

Diferente do teste anterior, este teste inicia o contexto da aplicação através da anotação @SpringBootTest e permite com que a mesma se conecte às dependências externas como banco de dados e o kafka. Ponto positivo.

No topo do teste iremos notar duas rotinas que cria e deleta pedidos e usuários da base de dados e executa antes e depois de qualquer caso de teste. Temos uma integração real com um banco.

Ao olhar o caso de teste vemos que a validação ocorre em cima do comportamento da API que está sendo testada. Espera-se um código de status OK, um retorno com valores específicos e que haja uma mensagem no tópico. De fato, o que nossa API realiza.

Mas o que tem de diferente para o teste anterior?

1 - Se porventura alguma configuração estiver errada, seja do banco de dados, do serviço de mensagem ou da aplicação, o erro é reportado.

2 - Se a consulta do banco estiver errada saberemos pois esperamos que seja retornado dados com valores específicos. Caso não exista, será retornado um código de status NOT FOUND.

3 - Caso a comunicação com as dependências externas venham falhar o próprio teste irá reportar, pois esperasse um código de status OK.

4 - O teste valida se a mensagem foi enviada ao broker, caso contrário o teste falhará e saberemos que a configuração está errada.

5 - Não há comportamento falso ou “mockado”.

Enfim, trazem mais segurança e assertividade!

Para finalizar, os testes de integração são essenciais para garantir o bom funcionamento da aplicação em ambientes reais, uma vez que validam a interação entre diferentes componentes, como banco de dados, brokers de mensageria e outros serviços externos. Diferentemente dos testes unitários, que isolam o comportamento dos objetos e podem gerar falsos positivos, os testes de integração verificam a aplicação em seu contexto completo, apontando erros de configuração ou falhas de comunicação com dependências externas. Embora sejam mais complexos de escrever, esses testes oferecem maior segurança ao validar o comportamento real da aplicação, prevenindo problemas que poderiam ocorrer em produção.

Ficou interessado pelo o conteúdo, deseja realizar testes de integraçãom com Kafka e não sabe como? Visite o este atigo abaixo:
Escrevendo Testes de Integração para Producers Kafka Com Spring Boot e EmbeddedBroker

Elucidando as diferenças entre associação, agregação e composição em POO

João Paulo Oliveira — Tue, 15 Oct 2024 17:14:52 +0000

Em POO (Programação Orientada Objetos) é comum utilizarmos um objeto para executar um comportamento específico dentro de outro objeto, ou até mesmo compor agregando mais informações. Isso ocorre quando há relacionamento os objetos dentro de uma sistema que se comunicam entre si.

Podemos definir relação entre objetos em três tipos: associação, agregação e composição. Abaixo falarei mais sobre eles.

Associação

Para identificar a relação de associação entre dois objetos basta entender se entre eles não existe dependência, ou seja, se são independentes.

Por exemplo, Aluno e Curso, um Aluno pode ter vários Cursos e consequentemente um Curso pode conter vários Alunos. Veja, o Aluno pode existir sem um Curso assim como Curso pode existir sem Aluno. Um relacionamento de muitos para muitos.

class Aluno() {
    val cursos: MutableList<Curso> = mutableListOf()
    fun add(curso: Curso) {cursos.add(curso)}
}

class Curso() {
    val alunos: MutableList<Aluno> = mutableListOf()
    fun add(aluno: Aluno) {alunos.add(aluno)}
}

A relação entre ambos é eventual.

Agregação

Diferente da associação, o relacionamento por agregação ocorre quando há exclusividade em uma das partes deste relacionamento.

Um exemplo, Funcionário e Departamento, Departamentos podem ter vários Funcionários e Funcionário pode estar vinculado a um Departamento. Porém perceba que Funcionário pode existir sem o vínculo ao Departamento e o mesmo não tem dependência de Funcionário para existir. Um relacionamento de muitos para um.

class Departamento() {
    val funcionarios: MutableList<Funcionario> = mutableListOf()
    fun add(funcionario: Funcionarios) {funcionarios.add(funcionario)}
}

class Funcionario() {
    val departamento: Departamento? = null
}

Composição

Muito parecida com agregação, o relacionamento por composição ocorre quando um objeto depende estritamente de outro objeto.

Por exemplo, Carro e Motor, Carro deve ter um Motor assim como a existência de um motor está particularmente ligada a existência de um Carro. Um relacionamento de um para um.

class Motor() {}

class Carro() {
    val motor: Motor = Moto()
}

Conclusão

Associação, agregação e composição é a dependência existente entre objetos e como eles se relacionam. Não há diferença na maneira de implementá-los e sim como irão se comportar. Devemos pensar o seguinte para quando utilizarmos:

Se ambos os objetos da relação são independentes, isto é uma associação.
Se um dos objetos da relação compõe o todo mas não é dependente, isto é uma agregação.
Se os objetos da relação dependem um do outro compondo o todo, isto é uma composição.

Saber identificar as diferenças entre os relacionamentos de objetos em POO e aplicá-las teremos um código mais coeso e manutenível.

Reduzindo a complexidade e facilitando a criação de testes com Fail Fast e Early Return

João Paulo Oliveira — Tue, 16 Apr 2024 00:10:14 +0000

Ao longo desses 3 anos como desenvolvedor de software pude perceber que muitos desenvolvedores não gostam de implementar testes, sejam eles unitários ou de integração, e que esse assunto é tedioso e trás dor de cabeça, afinal, quem nunca teve que criar casos de testes do zero ou até mesmo ajustar uma base inteira de testes após uma nova implementação? No entanto esquecemos que testes são primordiais para garantirmos a qualidade do nosso sistema, pois um bom código é um código bem testado, o design é apenas perfumaria.

Apesar desta introdução, esta leitura não é para discutirmos sobre testes e sim mostrar que um bom design pode nos auxiliar na escrita dos mesmo e assim entender o sistema, a lógica de negócio ou ramificações com pouco esforço cognitivo.

Vamos fazer o seguinte, partiremos da premissa de que testes visam validar o comportamento de um sistema resultando e em um estado positivo (esperado) e negativo (inesperado) e que para cada ramificação (if or else) será preciso criar cenários que contemplam tais comportamentos.

Tendo isso em mente vamos analisar o código e entender o que ele faz para criarmos cenários de testes para ele:

@RestController
@RequestMapping("/ecommerce/v1")
class ProdutoController(
       private val produtoRepository: ProdutoRepository,
) {

   @PostMapping("/produtos")
   fun helloWorld(
           @RequestBody solicitacaoCompraProduto: SolicitacaoCompraProduto
   ): ResponseEntity<Any> {
       val possivelProduto = produtoRepository.buscar(solicitacaoCompraProduto.identificador)
       if (possivelProduto.isPresent) {
           val produto = possivelProduto.get()
           if (produto.validade.isAfter(LocalDate.now())) {
               if (solicitacaoCompraProduto.lote == produto.lote) {
                   if (solicitacaoCompraProduto.quantidade < produto.quantidade) {
                       if (solicitacaoCompraProduto.precoUnitario  ==  produto.precoUnitario) {
                           produto.quantidade - solicitacaoCompraProduto.quantidade
                           produtoRepository.atualizar(produto)
                           return ResponseEntity.status(201).build()
                       }
                   }
               }
           }
       }
       return ResponseEntity.internalServerError().build()
   }
}

Podemos notar que a experiência de leitura de código é péssima e o esforço para entendê-lo é grande, o que não condiz com o seu tamanho de bloco já que ele é pequeno.

Depois de alguns minutos consigo compreender que o objetivo deste código é fornecer uma API Rest sendo um ponto de entrada para que seja possível a compra de um produto, validar as entradas do sistema e caso elas estejam todas de acordo com esperado é executado uma ação de redução de produto no estoque, consumando a compra, caso contrário é retornado um resposta de erro ao cliente.

Agora vamos refatorar um código para obtermos uma experiência melhor de leitura:

@RestController
@RequestMapping("/ecommerce/v1")
class ProdutoController(
       private val produtoRepository: ProdutoRepository,
) {


   @PostMapping("/produtos")
   fun helloWorld(
           @RequestBody solicitacaoCompraProduto: SolicitacaoCompraProduto
   ): ResponseEntity<Any> {
       val possivelProduto = produtoRepository.buscar(solicitacaoCompraProduto.identificador)
       if (!possivelProduto.isPresent) {
           return ResponseEntity.notFound().build()
       }


       val produto = possivelProduto.get()
       try {
           produto.deduzir(
               quantidade = solicitacaoCompraProduto.quantidade,
               lote = solicitacaoCompraProduto.lote,
               precoUnitario = solicitacaoCompraProduto.precoUnitario
           )
       } catch (ex: Exception) {
           return ResponseEntity.badRequest().body(ex.message)
       }


       produtoRepository.atualizar( produto)


       return ResponseEntity.ok().build()
   }
}

data class Produto(
       val identificador: Long,
       val nome: String,
       val precoUnitario: BigDecimal,
       val quantidade: Int,
       val validade: LocalDate,
       val lote: String
) {
       val estaVencido get() = validade.isAfter(LocalDate.now())


       fun deduzir(
               quantidade: Int,
               lote: String,
               precoUnitario: BigDecimal
       ) {
               if (estaVencido) {
                       throw Exception("O produto está vencido")
               }


               if (this.lote != lote) {
                       throw Exception("O lote é diferente")
               }


               if (this.quantidade < quantidade) {
                       throw Exception("Quantidade acima da capacidade")
               }


               if (precoUnitario != this.precoUnitario) {
                       throw Exception("Preço divergente")
               }


               this.quantidade - quantidade
       }
}

Podemos observar que temos um código limpo e objetivo. Consigo quase que de maneira intuitiva entender o que ele faz e visualizar suas regras para deduzir um produto.

Olhando para este código eu consigo contemplar diversos cenários de testes:

“Caso o produto não seja encontrado, retorne um status http 404”

“Caso o produto esteja vencido, retorne um status http 400 com a mensagem: O produto está vencido”

“Caso o lote do produto seja diferente, retorne um status http 400 com a mensagem: O lote é diferente”

E assim sucessivamente para os demais casos! E observe que os testes são em cima dos comportamento inesperado do sistema, pois quando todos os dados estiverem “okay” ocorrerá o comportamento esperado, e aí sim surge o caso de sucesso:

“Caso todas as entradas estejam corretas, retorne um http status 201”

E com casos mapeados podemos escrever testes baseando-se neles! Simples, né?

Mas é claro, essa refatoração segue três técnicas de programação, Tell Don’t ask, Fail Fast e Early Return.

Quero focar somente no Fail Fast e Early Return, dado que são simples e eficazes.

Basicamente Fail Fast, ou falha rápida, visa detectar e reportar erros do sistema imediatamente impedindo que ele prossiga com dados incorretos. Isso envolve verificações de condições de erro.

Podemos ver essa abordagem no método deduzir da classe Produto

fun deduzir(
               quantidade: Int,
               lote: String,
               precoUnitario: BigDecimal
       ) {
               if (estaVencido) {
                       throw Exception("O produto está vencido")
               }


               if (this.lote != lote) {
                       throw Exception("O lote é diferente")
               }


               if (this.quantidade < quantidade) {
                       throw Exception("Quantidade acima da capacidade")
               }


               if (precoUnitario != this.precoUnitario) {
                       throw Exception("Preço divergente")
               }


               this.quantidade - quantidade
       }

Já Early Return, ou retorno antecipado, retorna imediatamente um condição quando ela é atendida, evitando “ifs” aninhados e deixando o código mais objetivo.

Essa abordagem foi aplicada na classe ProdutoController quando verificamos se o produto não está presente

val possivelProduto = produtoRepository.buscar(solicitacaoCompraProduto.identificador)
if (!possivelProduto.isPresent) {
   return ResponseEntity.notFound().build()
}

Portanto, essas técnicas nos auxiliam reduzir a carga cognitiva para entender a complexidade de um sistema, nos ajudam nas escritas de testes já que por intermédio deles conseguimos compreender melhor os cenários para testá-los e de brinde temos um bom design código. Lembrando que design é perfumaria e que a qualidade de um código está relacionado a sua base de teste.

Se ficou curioso para saber sobre Tell Don’t Ask eu falo sobre ele nesta publicação https://dev.to/joaopolira/contribuindo-para-coesao-e-encapsulamento-atraves-do-design-de-codigo-tell-dont-ask-5gfi

Contribuindo para coesão e encapsulamento através do design de código Tell Don't ask

João Paulo Oliveira — Thu, 11 Apr 2024 12:44:56 +0000

Tell Don’t Ask, em português diga não pergunte, é um princípio de design de código no qual através de um objeto ocorre a combinação de dados e comportamentos. Este design traz a lembrança de que orientação objeto baseia-se no comportamento que determinado objeto tem sobre seus dados e assim transferindo a responsabilidade a quem é de direito.

As duas figuras acima ilustram a relação entre dois objetos e suas responsabilidades em que a primeira figura mostra o objeto “chamador” fazendo diversas perguntas a outro objeto e tomando decisões com bases nas respostas que recebe, já a segunda imagem representa uma comunicação na qual o objeto “chamador” apenas diz ao outro o que fazer e assim toda a lógica concentra-se em quem é o dono dos dados.

Por exemplo, vamos imaginar que temos uma classe denominada carro e ela tem como propriedade velocidade. Porém iremos considerar uma velocidade limite de 120km.

class Carro(
   var velocidade: Int
)

E ao utilizarmos uma instância desta classe queremos fazer com que o carro acelere.

fun main() {
   val carro = Carro(0)
   if (carro.velocidade < 120) {
       if ((carro.velocidade + 10) > 120) {
           carro.velocidade = 120
       } else {
           carro.velocidade += 10
       }
   }
}

E aqui é perceptível que há algo errado, pois quem chama o objeto precisa verificar se a incrementação da velocidade não irá ultrapassar o limite permitido, 120km.

Já utilizando o conceito Tell Don’t Ask o código ficará mais conciso e as responsabilidades são definidas de acordo com o escopo de cada objeto.

fun main() {
   val carro = Carro(0)
   carro.acelerar()
}

Agora quem chama o objeto não precisa implementar a lógica para incrementar a velocidade do objeto carro e sim somente chamar o método acelerar.

Já a classe carro fica responsável pelo o comportamento de acelerar, detendo toda a lógica de como fazê-la.

class Carro(
   private var velocidade: Int
) {
   fun acelerar() {
       if (this.velocidade < 120) {
           val novaVelocidade = this.velocidade + 10
           if (novaVelocidade > 120) {
               this.velocidade = 120
           } else {
               this.velocidade = novaVelocidade
           }
       }
   }
}

Além de contribuir para um código limpo e coeso onde as responsabilidades são divididas para cada objeto de acordo com seu escopo, também contribui para a reutilização de código, pois quem utilizar esta classe carro não precisará perguntar sobre a velocidade do carro para tomar decisões e sim somente dizer o que é necessário.

Portanto, Tell Don’t Ask só reforça o pilar do encapsulamento que encontramos ao estudar programação orientada a objetos. O encapsulamento consiste em adicionar uma camada de segurança à aplicação escondendo suas propriedades e expondo pontos de interações. Deste modo, os dados só podem ser manipulados internamente e quem utiliza só precisa dizer o que deseja e não perguntar, assim como fazemos com nossos controles remotos de televisão, não sabemos como ele funciona internamente e apenas precisamos dizer para que ele ligue a TV, mude de canal, baixe e aumente o volume, entre outras funcionalidades, mas como isso de fato funciona não é preciso saber.