Tudo é feito de Mini Stones ("pedrinhas" ou "tijolinhos")

Algumas vezes vamos empacar nos testes e ficarmos um pouco perdidos. Devemo-nos lembrar de que cada etapa conquistada é um tijolinho e o seu correto posicionamento determina as bases do nosso código e profissionalismo.

Bibliografia desta Unidade

1. Valente, Marco Tulio de Oliveira. Engenharia de Software Moderna. Marco Tulio de Oliveira Valente, 2020.

2. Freeman, Steve, and Nat Pryce. Growing Object-Oriented Software, Guided by Tests. Addison Wesley, 2010.

3. Manual de Devops: como obter agilidade, confiabilidade e segurança em organizações tecnológicas. Alta Books, 2021.

TDD Avançado

Hands-on: Algoritmo de Ordenação

Prática acompanhada pelo instrutor.

Hands-on: TAD de Pilha (Parte II)

Vamos começar a testar os seguintes comportamentos:

• Dada uma capacidade , ao empilhar mais um elemento (), dispare um erro de transbordamento (Qual o melhor nome possível?);
• A pilha precisa ter capacidade inicial para 10 elementos por padrão ()
• Deve ser permitido criar uma pilha com capacidade inicial maior que o padrão ()
• Dar capacidade de programação genérica (Java Generics)

Freeman & Pryce (2010)

• A publicação impactou toda a indústria de software comercial à época;
• Turbinou o uso do TDD para grandes projetos, do início ao fim;
• Teve observação dos autores do Agile (Kent Beck, Cunningham, Robert C. Martin, ...)

Os testes têm níveis e por onde começar

Vamos aos conceitos trazidos por Freeman e Pryce (2010).

• Aceitação (Acceptance): também chamado de Functional, System ou Customer Tests
• Integração (Integration)
• Unidade (Unit)

Teste de Aceitação (Acceptance)

Devemo-nos perguntar "O sistema inteiro funciona como o esperado?"

• O teste de aceitação adota a visão do usuário utilizando o sistema
• Uma nova feature (recurso): começamos a escrever um Teste de Aceitação
  • Se está falhando: o sistema ainda não entrega o que deveria
  • Deu "verdinho": cumprimos o critério de aceite. Recurso entregue.
• Atua como um guia de escrita de código

Exemplo de Critério de Aceite: Um Cliente pode pagar o cartão de crédito em determinadas bandeiras. (Valente, 2022)

Regra Principal do Teste de Aceitação: Sempre que possível, teste o sistema inteiro (início ao fim, end-to-end) sem chamar o código interno.

Isto é, devemos fazer como CAIXA PRETA. Testes de Caixa Preta significam que interagimos somente com a parte externa (outside), através de:

• Simulações de componentes de Interface Gráfica
• Chamando Web Services (via APIs)
• Analisando a estrutura de documentos gerados (parsing)

Como assim 'sem chamar o código interno'?

Devemos interagir com interfaces externas (como APIs)

Um Teste de Aceitação deve exercitar tudo

• Banco de Dados
• API de terceiros
• Servidor de Integração Contínua (Continuous Integration ou CI)

É o teste mais desafiador. Exige que tenhamos todos os componentes mais básicos primeiro. É comumente ignorado, elevando-se os riscos de regressão de funcionalidades.

Como se parece?

O Aspecto da Regressividade

É o simples fato de algo que funcionava e, depois de algumas alterações no sistema, deixou de funcionar. É onde mais nos aborrecemos enquanto usuários.

• Testes de aceitação de features terminadas: indicadores de regressão caso ocorra;

Sobre Integração Contínua (CI) e DevOps

• Elemento fortemente defendido em DevOps, mas já estava presente em Extreme Programming (XP);
• O que faz?
  1. Integra o código produzido por toda a equipe (Exemplo: após Merge de Pull Request);
  2. Compila e executa os testes (build and tests) "mergeados";
  3. Leva o código para Servidor de Delivery (Continuous Delivery);
  4. De Delivery vai para Deployment (Continuous Deployment)
  5. Entra em Operação.

Teste de Integração (Integration)

Devemos nos perguntar: o nosso código funciona com um outro e este outro não podemos alterar?

Integração é o ato de se juntar a nosso código com um outro que a equipe não pode alterar.

Podemos pegar nosso código e testar junto com os seguintes códigos externos:

• Mapeador de Persistência: Jakarta Persistence (JPA);
• Biblioteca de outro time que não podemos alterar.
• ...

Principal Propósito do Teste Integrado: verificar se abstrações construídas com o código dos outros irão funcionar como deveria.

Ok, mas um Teste de Integração é muito parecido com o Aceitação, certo?

Não. Em pequenas aplicações, quase sempre não precisaremos de Teste Integrado. Um de Aceitação já bastaria. Entretanto, Testes de Aceitação são mais lentos para verificar problemas de configuração. Aqui poderia fazer mais sentido o uso de testes integrados mais rápidos de serem executados.

Quando devemos escrever Teste de Integração?

• Depende da cultura;
• Tecnologias...
• Mas por experiência minha, pode ser útil para testar queries complexas com JPA (RAW SQL) e aspectos de conexão, persistência, etc
  • Regras de geração de Chave Primária (Incremental, por UUID, ...)
  • Saber se o código de Service (Domínio) funciona bem com queries elaboradas

Como se parece?

Fonte: Writing Integration Tests in Spring Boot App with JPA using JUnit5, Testcontainers and JPA Buddy

Teste de Unidade (Unit)

Devemos nos perguntar: nossos objetos fazem a coisa que deveria ser feita? É fácil de trabalhar com eles?

Como se parece?

Teste Unitário promove código bem projetado (well-designed)

• Forçamos a classe a ser mais facilmente testada;
• Dependências externas precisam ser substituídas;
• Responsabilidades precisam ser claras;

Teste Unitário alcança as 2 qualidades mais desejadas de um software: código fracamente acoplado e com alta coesão.

Calma... O que é Acoplamento e Coesão?

São uma medida da facilidade com que conseguimos alterar o comportamento de um código. É uma medida aproximada.

Acoplamento

Alto acoplamento: alterou uma parte do sistema, todas as restantes quebram. Alterações exigem reconstrução de todo o sistema.

Fraco acoplamento: alterou uma parte, poucas ou nenhuma parte do sistema precisa ser alterada.

Coesão

Medida de responsabilidades de uma unidade (pode ser uma função ou classe)

Baixa Coesão: uma unidade que faz muita coisa que não deveria

Exemplos:

1. Uma Classe que cuida do parse de Datas e de URLs ao mesmo tempo. O que uma coisa tem a ver com outra?

2. Uma Classe que deveria processar URL mas só verifica partes de uma URL e não ela toda. Isso força a procura de outros processadores para complementar o trabalho que ela deveria fazer.

Alta Coesão: uma unidade faz o que deveria e faz completamente

Seja num projeto legado sem testes ou novo: Teste de Aceitação é quem manda

Devemos começar pelos Testes de Aceitação a cada nova Feature

• Escreva um código de teste que falha;
• Vai continuar falhando até que o sistema fique completo.

Vão ficar falhando???

Calma. É assim mesmo. São testes que vão demorar a ser executados. Precisamos esperar pelos testes integrados e unitários.

TDD aplicado a um projeto inteiro (sem exceções)

Só seguirmos a Golden Rule do TDD

Escreva um teste que irá falhar!

Por onde exatamente começar?

Freeman & Pryce apontam para iniciarmos pelos Testes de Aceitação.

O que devemos fazer de fato em primeiro lugar ao escrever uma classe ou feature?

Escreva o Caso de Sucesso mais simples possível: aqui Freeman & Pryce pedem maior cuidado!

Freeman & Pryce

• Existe uma suposição popular para iniciarmos pelos Casos Degenerados

"The simplest thing that could possibly work" (Kent Beck)

• Uncle Bob incentiva começarmos com Casos Degenerados (Clean Craftsmanship)

• Entretanto, Freeman & Pryce afirmam que isso entrega pouco valor ao sistema. Não dão feedback interessante sobre a validade das ideias de negócio. Os Clientes ficam mais preocupados. Afeta a moral da equipe.

Como Freeman & Pryce priorizam a Lista de Casos de Teste? Exemplos

1. Liste os casos de sucesso

• Cliente compra produto na loja, recebe o produto;
• Um cartão de atividade é criado, registrando a tarefa a ser feita.

2. Liste os casos de falha ou degenerados

• Cliente compra um produto fora de estoque. A operação deve ser impedida.
• Cartão de atividade com identificador inexistente é procurado no sistema. Deve dizer que não foi encontrado.

Uma possível análise

A visão de Bob é útil para exercitar TDD e para criar bibliotecas, frameworks e etc (software de base).

A visão de Freeman & Pryce é útil para entregar valor em produtos de maior retorno comercial.

Entretanto, Anote os casos degenerados/falha num bloco de notas ou registre num Card de subtask. Caso esqueçamos, isso vai virar a futura Issue que o cliente vai descobrir.

Não seria mais fácil começar pelos testes unitários?

É comum acharmos que implementar classes de Domínio (Modelo) poderia ser mais simples. Entretanto, Freeman & Pryce apontam que esta abordagem torna propensa a criação de código desnecessário. (Pg. 43)

Poderíamos iniciar pela modelagem UML?

• É válido como compreensão inicial;
• Entretanto, na maioria das vezes introduz excesso de classes e abstrações;
• Prejuízo a performance em larga escala.

Ilustração do problema: Criação do Jogo de Boliche em UML (Clean Craftsmanship, pg. 81)

Por TDD: apenas 1 classe

Hands On: Exercitando Programação Web com TDD de ponta-a-ponta

1. Vamos praticar a criação de Teste de Aceitação com Cucumber em Java (boilerplate já criado)

2. Escrever Teste Integrado para testar Controllers e JPA

3. Escrever Teste Unitário para validar comportamentos de classes

Lista de Casos de Teste

Sucesso

(1) Como Cliente, Eu gostaria de consultar produto para comprar.

Degenerado/Falha

(2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

Montando nosso Walking Skeleton

Vamos iniciar a fase da chamada ITERAÇÃO ZERO.

É uma etapa de infraestrutura. Segundo Freeman & Pryce, não devemos contar isso nas iterações comuns. Após a conclusão da iteração zero, o projeto se inicia de fato.

Devemos procurar a arquitetura mais simples e ao mesmo tempo completa. Vai precisar de um Banco de Dados? Já o coloque. Vai precisar de uma API REST? Já a coloque.

Importante evitarmos o BDUF (Big Design Up Front)

Devemos evitar de construir classes, algoritmos e tomar decisões de arquitetura cedo demais (Freeman, pg. 35)

O Agile orienta descobrir os detalhes a medida que as iterações avançam, o software é entregue e o feedback real é tomado.

O Caso (1) vai atuar como um orientador para o primeiro teste. O Walking Skeleton será construído para atendê-lo.

Arquitetura Mínima (PlantUML)

Infraestrutura mais básica possível

• JDK 21
• Spring Boot 3
• Banco de Dados H2 (SQL, em memória RAM)
• Framework de Teste Integrado e Unitário: JUnit 5
• Biblioteca de Asserções: AssertJ
• Framework de Teste de Aceitação: Cucumber

Chamamos Teste de Aceitação como UAT - User Acceptance Test também.

Checklist

• Faça clone do projeto
• Aprender a executar 3 tipos de teste: e2e, it e ut
• Visualizar um relatório de Integração Contínua (CI: GitHub Actions)
• (1) Como Cliente, Eu gostaria de consultar um produto para comprar (Walking Skeleton)
• (2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

Clonando

Executando todos os testes

Executando todos os testes unitários (ut) e integrados (it) somente

Executando todos os testes integrados (it) somente

Executando todos os testes unitários (ut) somente

Executando todos os testes de aceitação (e2e) somente

Aconselho a evitar este tipo de comando. Um e2e deve exercitar
todos os testes também. Algumas IDEs oferecem uma maneira de executar somente os testes integrados por meio de plugins, devendo ser usado com muita cautela.

Checklist

• Faça clone do projeto
• Aprender a executar 3 tipos de teste: e2e, it e ut
• Visualizar um relatório de Integração Contínua (CI: GitHub Actions)
• (1) Como Cliente, Eu gostaria de consultar produto para comprar. (Walking Skeleton)
• (2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

Visualizar um relatório de Integração Contínua (CI: GitHub Actions)

Mais à frente será explicado em detalhes como funciona a prática de Integração Contínua.

Onde ver o relatório? Clique em Forkstore - GitHub Actions.

A partir do repositório de exemplo, vamos fazer um commit vazio e dar um push para disparar o servidor de CI. Vamos vê-lo em ação.

Atenção: ao visitarmos o relatório gerado, vamos ver algo assim

Está certo mesmo?! Não! É muito fácil sermos enganados por automações de verificação de cobertura e ferramentas de teste.

Não temos nada e a ferramenta jacoco-badge-generator disse que está 100% coberto! Conclusão: desconfie um pouco de ferramentas!

Checklist

• Faça clone do projeto
• Aprender a executar 3 tipos de teste: e2e, it e ut
• Visualizar um relatório de Integração Contínua (CI: GitHub Actions)
• (1) Como Cliente, Eu gostaria de consultar produto para comprar. (Walking Skeleton)
• (2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

(1) Como Cliente Eu gostaria de consultar produto para comprar.

Abra o arquivo ClienteConsultaProdutoAComprar.feature (pasta test/resources/org/forkstore)

Por enquanto vamos ignorar

Delineação do Cenário

Evite colocar acentuações em delineação de cenário e fundo.

1. Quando o cliente procura por categoria

Deve receber uma lista de produtos correspondente à categoria

• Visite a classe ProcuraProdutoPorCategoria.java no pacote org.forkstore.e2e

2. Então uma lista de produtos deve aparecer com os produtos pertencentes a uma categoria

Verificar se o teste acima funciona. Depois devemos retirar a implementação abaixo.

Crie uma classe chamada ProductController.java em main/java/org/forkstore (é o pacote org.forkstore)

3. Refatorando o teste

4. Implementando teste "E cada produto mostrado aparecerá com <nome>, <quantidade> e <disponivelAVenda>

Exercitando o Banco de Dados

5. Simulação do cadastro de 3 produtos

A classe PreparacaoDaHistoria fica em org.forkstore.e2e

Product deve ser um Entity

Teremos muitos erros ainda. Vamos corrigindo aos poucos.

Uma classe como esta satisfaz a criação da massa de dados de testes

Soa estranho... Não temos sequer os campos para o BD

Com setters vazios, não se faz nada! Mas tudo bem, vamos prosseguindo.

À frente, algum teste vai pedir uma implementação mais esperta.

Os testes devem passar.

6. Refatorando o controller

Resolvendo alguns problemas gerados pela refatoração

A refatoração aqui apontou que nossa fase de criação de dados de teste está falha.
Não tem problema, vamos consertá-la.

Classe Product

Existe um recurso interessante de algumas IDEs chamado Multi-selection.
Podemos reaproveitar setters e transformar em campos. Deve ficar assim:

Resolve? Ainda não. Temos ainda a falta de setters. Solução rápida: Lombok Setters.

Com isso, teremos setters sem precisar de utilizar recursos de IDE. O Lombok permite
gerar código no momento que o compilador gera a AST (Abstract Syntax Tree).

Mesmo assim teremos falhas

Solução? Adicione getters.

Ainda teremos mais erros. O primeiro teste funciona, mas os outros 2 não.

Num teste teremos isso

Noutro, algo semelhante. O que pode ser?

Importante: Etapas como Fundo (Background)

Isso faz com que cada Exemplo de um cenário delineado tenha a execução do método
PreparacaoDaHistoria.produtosCadastradosNaLoja(). Isso vai poluindo a base de dados.

Solução? Vamos limpar a base de dados com um recurso chamado Hooks

After: quer dizer que o método cleanUp vai ser chamado depois do exemplo de teste de um cenário delineado tiver sido executado.

Agora todos os testes passam. Vamos ver como vai ser o trabalho com um CI.

7. Continuous Integration (CI) com GitHub Actions

• O teste de aceitação inicial está passando. Vamos verificar se o código submetido ao GitHub consegue passar através de um servidor de integração contínua.

Como funciona o GitHub Actions?

Event = Evento que ocorre num repositório.

Exemplo: git push, pull request, ...

Observa-se que no arquivo .github/.github_action.yml temos

• Quer dizer, toda vez que fizermos um Pull Request com as branches de destino sendo feature/*, /release/* e main, algumas etapas serão executadas sequencialmente.

Neste workflow de exemplo, temos 1 job que vai rodar uma sequência de comandos de terminal num Ubuntu Linux.

Workflow = Sequência de Jobs (tarefas automatizadas)

Job = Sequência de Tasks (conhecidas como Steps)

Step = Task = Coleção de comandos de shell, setup task ou action

Runner = É um servidor que roda os workflows definidos na pasta .github/workflows. Definimos com a expressão runs-on relativa ao job.

Primeira coisa a se fazer: pedir para o CI dar um git checkout na branch

uses: vai executar uma Action como parte da step. Logo, o checkout será feito logo no início da step. Se estiver fazendo um commit e push na branch ABC, é nesta branch que será feito o checkout.

Depois, pedir para o CI configurar o ambiente com as ferramentas para rodar nosso projeto em Java 21 com Maven

Ao todo temos 6 steps. São

Step 1: CI Info

• Para mostrar informações úteis como a branch em que nos encontramos.

Step 2: Build and All Tests

Step 3: Build Tests (Unit and Integration)

• Se tiver numa branch de feature, chame somente os testes unitários e integrados

Step 4: Generate JaCoCo Badge

• Gera um arquivo .svg como

Para incluir este badge acima no README, precisa-se incluir outra Step para commit (devido à controvérsia de bots, preferi omitir).

Step 5: Log coverage percentage

Step 6: Upload JaCoCo coverage report

Links úteis do GitHub Actions

Entendendo como funciona o GitHub Actions

Jobs e Workflow

Lista de Runners disponíveis

Vemos no CI que todos os testes passam e que o primeiro teste de fato passa.

Temos que cumprir a regra do Freeman & Pryce: um Teste de Aceitação deve falhar.

Vamos apagar o código de produção e subir para ver o CI falhando nas asserções.

Ao subirmos precisamos ver isso no CI

Revisando o Checklist

• Faça clone do projeto
• Aprender a executar 3 tipos de teste: e2e, it e ut
• Visualizar um relatório de Integração Contínua (CI: GitHub Actions)
• (1) Como Cliente, Eu gostaria de consultar produto para comprar.
  • Walking Skeleton exercitou API e Banco de Dados
• (2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

Relembrando

8. Vamos precisar criar um teste unitário. O que podemos testar?

Devemos nos perguntar: nossos objetos fazem a coisa que deveria ser feita? É fácil de trabalhar com eles?

Quais objetos podemos pensar? Do DDD (Domain-Driven Design), temos:

• Entidades (camada de Domínio)
• Caso de Uso (camada de Domínio)
• Controllers (camada de Infraestrutura)
• Repositories (camada de Persistência)

Os Casos de Uso oferecem maior facilidade. Podemos isolar os componentes externos mais facilmente através de Test Double (Dublê de Teste).

Implementando um Caso de Uso através de um Service

Podemos utilizar uma classe de Service do Spring para implementar as regras de negócio de um Caso de Uso.

Alguns preferem ainda criar uma nova classe de Caso de Uso. Opto pela simplicidade para evitar proliferação de classes.

Claro, vamos começar pelo teste de uma classe que ainda não existe

Um código mínimo

É o coração da nossa intenção. Queremos chamar o caso de uso da procura de um produto por categoria.

Vamos resolvendo as falhas...

Teremos a falha

Solução: instanciação

Vamos colocar a primeira asserção

Falha. Resolvendo...

Sucesso! BIZARRO?! Calma...

Vamos verificar se, ao buscar por categoria, um repository é acionado para buscar os dados.

A falha diz tudo. repository precisa ser um Mock instanciado. Vamos instanciar então...

repository precisa ser um Mock!

Problema-chave

Podemos aprender a programar assim, analisando respostas das falhas. findByCategory nunca é chamado de fato.

Vamos fazer com que seja chamado forçadamente.

Falha. Corrigindo.

Vai falhar novamente.

E agora?

Ou de forma abreviada

Resolvido. Sabemos que findByCategory é chamado na regra de negócio.

No entanto, o código está nos enganando. Este retorno assim precisa mudar.

Como? Vamos deixar os testes ainda mais específicos para provocar maior generalidade.

Uma nova categoria pode retornar 2 produtos.

Agora vamos ter a falha que precisamos.

Qual solução?

• A mais óbvia

Resolve, mas cria um problema: os ifs estão gerando duplicação. Vamos refatorar e
procurar uma forma mais inteligente de remover a duplicação.

Maneira singela: jogue a duplicação para longe do System Under Test

E como a regra de negócio só tem feito 1 ação, já colete o seu retorno. Se porventura precisarmos de adicionar novas regras, é só reescrever.

Teremos problemas de compilação. Vamos ajustar a assinatura do método.

Ajustando

Isso resolve a compilação. Entretanto, os testes falharam.

Qual a razão?

Um objeto "mockado" ou o ato de "mockar" em si é um tipo de interceptação ou "sequestro" da CPU.

O que vai acontecer com a CPU?

1. O objeto service vai receber a referência de um objeto anotado com @Mock caso a utilize. E realmente vai ser usado, pois o construtor de ProductService vai recebê-la.

2. O campo repository anotado com @Mock indica que o objeto do tipo ProductRepository terá sua instanciação interceptada. Ela vai ser substituída por um outro objeto que vai atuar como um dublê.

No fim das contas, repository será um Doppelganger.

Como isso funciona exatamente? Estude um outro grande tópico chamado Java Reflection API. As frameworks de Mock a utilizam.

Esse dublê, por outro lado, não sabe o que vai imitar. Inicialmente, o objeto mockado apenas imita as assinaturas dos métodos da classe a ser imitada.

Como programadores, somos responsáveis pelo "Jogo da Imitação". Como não colocamos instruções de imitação, nosso código falha.

Inserindo instruções de imitação, atuação ou stubbing

Pronto, resolvido! Mas vamos fazer limpezas.

Limpe os ifs que estavam aqui. Não são mais necessários.

Isto aqui está uma bagunça. Vamos sair disto

Para isto

Vamos dar um nome decente ao teste.

Mas e esses new Object()? Calma, temos que ter testes específicos para nos criar a necessidade de mudar.

Terminamos nosso teste unitário. Por favor, verifique se está passando.

9. Implementando um Teste Integrado. Relembrando

Principal Propósito do Teste Integrado: verificar se abstrações construídas com o código dos outros ou externos irão funcionar como deveria.

Só lembrar disto: testar com um código que não podemos alterar.

Qual teste é o melhor candidato? Testar nosso repository com JPA (Jakarta Persistence).

Temos

Vamos lá

Resolvendo falhas

Estamos procurando testar a interação com um Banco de Dados. Existem particularidades a serem testadas em qualquer banco de dados. Qual aspecto degenerado de um objeto de um BD?

Vamos testar a presença de chave primária

Falha. Como resolver? Vemos que a assinatura abaixo está nos tirando a possibilidade de definir o método getId().

A classe Object vai dar lugar à sua herdeira: Product

Em TDD, viramos artesãos: do barro, das coisas sem forma, nascem as coisas bem definidas.

Vamos ter uma falha em outro código

Simples. Mas isso vai gerar uma cascata de erros. Outros testes acabam sendo dependentes deste código. Vamos precisar consertá-los.

Consertando

transforme em

Lá embaixo, devemos mexer

Ok. Devemos retestar as classes que tiveram alterações? Sim, mas recomenda-se focar na classe de teste escolhida. No caso, temos que nos focar em ProductRepositoryIT.

Se estiver treinando via linha de comando, o Maven permite individualizar a classe de teste.

Agora podemos implementar getId()

Long? Tradicionalmente em mapeamento Objeto-relacional, IDs podem ser muito grandes. Long é o suficiente e de melhor capacidade.

Resolvido. Teremos erro lógico.

Isso se deve porque estamos fazendo

Corrija

Nova falha ainda

Solução

Asserção para ID 2

Compreensível

Rápido

E agora? Simples.

Resolve. Entretanto, estamos criando assim um tipo de persistência em memória RAM.

Refatorando para dar suporte ao JPA.

O teste integrado tem a necessidade de testar um código externo fora de nosso controle. O teste que fizemos anteriormente é um Unitário ainda. Vamos transformar em Integrado.

Transformações. Temos

Falha ainda. Vamos melhorar as asserções.

para

Fica mais nítido o problema. getId retorna o valor do campo id que é nulo. Long não é um tipo primitivo, é um tipo chamado Wrapper Class. Ele "embala" um primitivo.

A razão da falha está no fato de que os objetos estão sendo criados sem definir ID.

Para resolver esse de forma efetiva, podemos seguir uma direção mais interessante. Transformar ProductRepository num CrudRepository.

Vamos sair disto

Para isto

Automagicamente, vamos ganhar de brinde a implementação de findByCategory() que o JPA já tem pronta. É o reuso na sua maior expressão.

Falha de compilação ainda.

Não podemos instanciar um interface.

Solução: Injeção de Dependência

Só podemos injetar uma dependência se um terceiro instanciá-la antes para a gente. Quem vai fazer isso por nós?

@DataJpaTest

Isso vai fazer o Banco de Dados H2 sair da jaula!!! Vamos precisar dele para os testes fazerem sentido. Alcançamos o verdadeiro propósito do teste integrado.

Agora teremos

Definimos então o campo

Calma

Por que será? Como o banco de dados foi iniciado, a tabela de Product está vazia. Só a gente acionar a persistência.

Falha.

Isto se deve à falta de atribuição de ID. Dá para resolver rápido sem gambiarras.

Voltamos ao

Minha hipótese: category não está sendo cadastrado no banco

Vamos utilizar o pattern Builder fornecido pelo Lombok

Resolvido!

Limpando o teste e colocando um bom nome

Observamos que os logs mostram os comandos do SQL. Isso nos ajuda a saber que de fato um banco de dados relacional foi usado.

10. Implementando Teste Integrado de Controller

Um Controller é um componente de Infraestrutura. O propósito dele é de cuidar do recebimento, processar e dar resposta a uma requisição.

Na Arquitetura RESTful, um Controller recebe uma requisição HTTP e responde sob HTTP através de uma route e um verbo (GET, POST, PUT, ...).

Vale ressaltar que para ser RESTful é preciso cumprir demais requisitos fora de escopo deste material. (Veja sobre HATEOAS).

Comecemos. Vamos usar uma framework chamada Spring MVC Test ou MockMVC. É mais confiável do que testar as classes de controller chamando seus métodos, desprezando-se as partes importantes.

MockMVC nos permite testar: request mappings, data binding, message conversion, type conversion, validation e etc.

Falha. Resolvendo

Atenção!

Isso nos faz lembrar de que na Injeção de Dependência, a instanciação de um objeto vem de um terceiro que vai instanciar para a gente.

Solução

Adicionando. Já temos nossa falha de lógica!

Seguindo. Vai dar verde. Rota vai retornar 200 Ok.

Exija que o conteúdo da resposta do servidor seja do tipo application/json.

Isso ainda não resolve. Mesmo erro. Mas é fácil resolver.

Testando se a query param foi recebida. Falha.

Resolva

Limpe

Aconselho parar por ai. Está ótimo!

Um Controller vai ser ainda testado pelos testes de aceitação. Não vamos testar nada mais além do que aspectos de comunicação do REST com ele.

Alguns desenvolvedores inserem testes como para verificar se o código do serviço será de fato acionado dentro do controller. Existem outras maneiras de atestar isso.

Temos sempre que ter o cuidado de separar as responsabilidades de cada componente e delimitar o número de dependências de teste.

Existem um tópico mais avançado que trata sobre isso: Fragilidade dos Testes.

11. Vamos fazer os últimos ajustes

Ao executarmos todos os testes, somente os testes de aceitação falham ainda.

Lendo o log de erro, notamos

Temos um teste falhando. Só seguir o TDD, vamos fazer passar.

Já ajuda um pouco. Entretanto,

E assim?

Ainda não, mas melhorou.

Um pouco mais inteligente: que tal adicionarmos logo o objeto do service ProductService e chamar o método searchByCategory?

e

E agora?

É um bom sinal. Minha hipótese é de que o controller já está utilizando o service e o banco de dados está sendo consultado.

Por acaso cadastramos os produtos de exemplo? Vamos lá...

Quase lá!!! Adicione os campos que o cliente pediu.

Teremos falha de compilação. Resolvendo...

Haja coração!!!! As madrugadas me revelam que cada exemplo de teste polui o banco de dados. Vamos limpá-lo.

Acabou!!!

Feature terminada sucesso!!!

Fica para a próxima Copa

• Faça clone do projeto
• Aprender a executar 3 tipos de teste: e2e, it e ut
• Visualizar um relatório de Integração Contínua (CI: GitHub Actions)
• (1) Como Cliente, Eu gostaria de consultar produto para comprar.
  • Walking Skeleton exercitou API e Banco de Dados
• (2) Como Cliente, Eu gostaria de receber um aviso de que, ao procurar um produto por categoria indisponível, Eu receba uma mensagem me notificando.

Acaba por aqui?!

Não. TDD pode servir como um orientador disciplinar para se aprender a programar de maneira eficaz e gerar maior confiança no código. Exige mais repetição e variação da prática com diversos exemplos.

É só o início.

POI.