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