Artigo Java Magazine 62 - Testando com Mocks de forma fácil

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista Java Magazine Edição 62.

Esse artigo faz parte da revista Java Magazine edição 62. Clique aqui para ler todos os artigos desta edição

Testando com Mocks de forma fácil

Criação de testes unitários com Spring e EasyMock

Faça com que o trio EasyMock, Spring e JUnit ajude a criar testes unitários de forma rápida e fácil

De que se trata o artigo:

O artigo apresenta uma forma criativa de criar testes unitários com a biblioteca EasyMock, focando no que deve realmente ser testado e eliminando a dependência de objetos secundários ou de infra-estrutura.

 

Para que serve:

O artigo introduz a biblioteca EasyMock para poder auxiliar e incentivar o leitor a utilizar testes unitários usando Mock Objects (objetos “falsos”) em situações onde a dependência torna-se um problema para criação e/ou manutenção dos testes unitários. É apresentada também, uma técnica com Spring para geração automática de código para a criação dos Mocks a partir da execução de teste existentes.

 

Em que situação o tema é útil:

Se você considera essencial a criação de testes unitários dentro do seu ciclo de desenvolvimento, sabe o quanto pode ser difícil criar código de testes unitários onde o uso de classes não diretamente relacionadas ao que está sendo testado deve ser escrito e mantido. Em uma situação como essa o EasyMock ajudará a substituir essas dependências, e a geração de código para os testes fará com que esta substituição seja menos dispendiosa.

 

Testando com Mocks de forma fácil:

Simplificação de testes unitários. Essa é a premissa do artigo, onde é apresentado para o leitor uma forma de abstrair os elementos não essenciais ao objetivo do teste, substituindo-os por objetos “de mentira” utilizando a biblioteca EasyMock. Dessa forma, o artigo demonstra através de exemplos como escrever os testes desde o início pensando em Mocks. Além disso, é construído de forma simples e fácil um pequeno programa com Spring capaz de gerar boa parte de um novo código de testes, baseado em Mocks, a partir da execução dos testes unitários já existentes, ajudando assim, a acelerar a conversão para o novo formato.

 

Os testes unitários deixaram de ser novidade há um bom tempo, e hoje estão cada vez mais presentes no dia-a-dia das empresas de desenvolvimento de software. A partir deste grande envolvimento e aceitação das empresas com o teste unitário, podemos destacar dois importantes fatores: Qualidade de Software e JUnit.

Por que JUnit? O JUnit foi a ferramenta que faltava para pôr em prática a realidade de construir e executar testes unitários. Ficou fácil notar como as metodologias ágeis ganharam um grande impulso e força após o JUnit tornar viável algumas das lições divulgadas por essas metodologias.

Vamos fazer um paralelo com outros setores da indústria onde os testes de qualidade já estão presentes e postos em prática há muito tempo. Tomemos como exemplo uma fábrica de pneus. Imagine você, se para cada pneu produzido dessa fábrica fosse necessário colocá-lo em um veículo com motorista e fazê-lo rodar por alguns quilômetros simplesmente para testá-lo? Seria exagero, sem contar alguns desperdícios como um motorista disponível, combustível, o trabalho de colocar e tirar pneus do carro, etc.

Foi nesse ponto que a indústria de fabricação de pneus (entre outras) evoluiu e aprimorou os testes de qualidade. Vejamos, a borracha que será usada na fabricação e vulcanização do pneu é avaliada e deve estar dentro de um padrão de aceitação exigido pela indústria. O processo de vulcanização é monitorado, e por fim as unidades produzidas são testadas e avaliadas nos quesitos de elasticidade, torção, resistência, e na fase final o pneu é submetido a uma esteira onde percorre um curto trecho em um ambiente muito similar a uma estrada ou avenida.

A disciplina da Engenharia de Software procura trazer os mesmos métodos “industriais” à produção de software. O apelo das metodologias ágeis é disponibilizar ferramentas simples e pragmáticas, focadas em obter excelentes níveis de qualidade.

Voltando ao paralelo, iremos falar nesse artigo sobre como construir e executar testes unitários sem a necessidade de ter as partes colaboradoras sempre disponíveis. É como se estivéssemos falando, no caso do pneu, de como testá-lo sem a colaboração do veículo.

Nossa intenção aqui não é abordar profundamente JUnit ou qualquer metodologia, pois iremos nos focar na realização de testes através de objetos “de mentira”.

Exemplo: Banco Central

Usaremos como exemplo uma operação de transferência de valores entre contas de diferentes instituições financeiras, onde queremos testar a lógica de transferência em si, e não a disponibilidade e o acesso às instituições financeiras, às quais chamaremos a partir de agora de bancos.

 

Figura 1. Diagrama de Classes do projeto exemplo.

Veja o diagrama de classes apresentado na Figura 1. A interface Banco é ponto de partida dessa transação de transferência, através do método transferenciaInterbancaria(), cuja assinatura é:

 

void transferenciaInterbancaria (ContaLocal origem, Conta destino, BigDecimal valor)

 

A conta de origem, aqui representada pela classe ContaLocal, é uma conta totalmente acessível pelo Banco onde está sendo iniciada essa transação. Porém, a conta de destino, representada pela classe Conta, pode pertencer a outro banco, fora do domínio do banco originário.

É nesse momento que o Banco pede uma ajuda para a interface BancoCentral"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?