Evolução do Design através de Testes e o TDD

Transcrição

1 c a p a Lucas Souza (lucas.souza@caelum.com.br): é bacharel em Engenharia da Computação pela Universidade de Ribeirão Preto, possui a certificação SCJP e trabalha com Java há 4 anos. Atualmente é desenvolvedor e instrutor pela Caelum. Entusiasta de metodologias ágeis e editor-chefe do InfoQ Brasil. Paulo Silveira (paulo.silveira@caelum.com.br): é bacharel e mestre em Ciência da Computação pela USP, trabalha com Java há 10 anos, sendo 6 anos com consultoria, desenvolvimento e treinamento na Caelum. Evolução do Design através de Testes e o TDD Como os testes de unidade impactam diretamente no design da sua aplicação Os testes de unidade já são obrigatórios em muitas empresas e ganham cada vez mais importância no mercado. Ainda é considerado por muitos apenas como uma forma de demonstrar a corretude do seu sistema, mas os testes de unidade vão muito além: são uma forma de validar o design de sua aplicação, garantindo a possibilidade de evoluir, mudar e refatorar o seu código. Veremos, através de um exemplo, como os testes, aliados ao Test Driven Development, possuem o potencial de manter seu design com um baixo acoplamento. Testes de unidade têm se tornado cada vez mais imprescindíveis no atual mercado de desenvolvimento de software. Além de ser uma maneira de diminuirmos a possível quantidade de problemas que o software pode ter, a principal característica dos testes de unidade sem dúvida é aumentar a qualidade do código, diminuindo o acoplamento e obtendo assim um software de fácil manutenção e extensão. Devido a sua existência, a equipe se sente tranquila para efetuar refatorações, manutenções ou até mesmo fazer a adição de novas funcionalidades. Porém obter um código com baixo acoplamento e que seja de fácil manutenção não é uma tarefa trivial de ser alcançada. O que ocorre, muitas vezes, é que ao desenvolver alguma funcionalidade, tomamos decisões que podem tornar o código difícil de ser testado. O Test Driven Development (TDD) é uma técnica de desenvolvimento que pode ser utilizada para evitar esse tipo de problema. O TDD nos questiona frequentemente sobre questões como o Princípio da Responsabilidade Única (SRP) e Não Se Repita (DRY), e esses questionamentos surgem quando sentimos alguma dificuldade para criar o teste. Utilizando TDD o design das classes emerge de forma poderosa (pela facilidade de extensão) e simples (pela fácil manutenabilidade). TDD não substituirá seus princípios e decisões sobre o design ou mesmo seus diagramas UML, a ideia é validar e melhorar suas decisões de design. TDD é uma técnica que ajuda na criação e evolução do design, mas não é a única maneira de fazê-lo. Nosso objetivo aqui é demonstrar na prática como o TDD vai acelerar essa evolução de design. 32

2 Exemplo: enviando um ao cadastrar um novo usuário Para nossa demonstração, considere que em um sistema precisamos que, ao adicionar um novo usuário, um seja enviado dando boas-vindas a esse cliente. Em um pensamento rápido, podemos criar um método estático envia dentro de uma classe EnviadorDe . Invocaremos esse método de dentro do nosso NovoUsuarioController, que será responsável por adicionar o novo usuário no banco de dados e enviar o de boas-vindas, como nas Listagens 1 e 2. Para isso, considere que também temos uma classe DaoFactory, responsável por retornar as classes do sistema responsáveis pela persistência de dados. Listagem 1. Classe NovoUsuarioController. EnviadorDe .envia (usuario.get ()); Listagem 2. Classe EnviadorDe . import org.apache.commons.mail. exception; import org.apache.commons.mail.simple ; public class EnviadorDe { public static void envia (string para) { try { Simple = new Simple (); .sethostname( smtp.server.com ); .addto(para).setfrom( lucas.souza@caelum.com.br, Lucas Souza ).setsubject( Confirmação de cadastro ).setmsg( Seja bem-vindo ).send(); catch ( Exception e) { e.printstacktrace(); É um código que parece funcionar, mas será que possui um bom design? Está desacoplado o suficiente? Para garantir o funcionamento desse método de adição de novo usuário, será criado um teste de unidade, que verifica se o foi enviado corretamente. A Listagem 3 mostra como podemos preparar o teste de unidade. Listagem 3. Cenário do teste de unidade da classe NovoUsuarioController. Com o usuário e o controller criados, estaríamos prontos para fazer as asserções e assim garantir que o método adiciona() está funcionando como esperado. Mas como verificar se um está sendo enviado para o usuário? Se mantivermos o teste com o código assim, um de verdade será disparado para esse cliente cada vez que o executarmos! Uma alternativa seria, antes de iniciar os testes, levantar um servidor SMTP que apenas simulasse o envio do . Poderíamos até fazer isso via Java no setup do teste, programaticamente, ao usar um servidor como o Apache James. Porém, com isso, começamos a nos complicar com um teste de unidade que deveria ser bastante simples. Dessa forma, ele estaria se tornando um teste de integração. O problema neste caso é que não temos como verificar de uma maneira fácil se o foi enviado, afinal, dentro do método adiciona() mantemos um acoplamento muito forte com a classe EnviadorDe . Isso ocorre devido a ela ser uma dependência que não podemos mudar com facilidade. Outra maneira um tanto complicada de evitar que o método de envio de fosse realmente invocado (para não enviar o e apenas testá-lo) seria, através de um classloader customizado e manipulação de bytecode, os quais trocariam a implementação desse método. Alguns frameworks de mock (se não sabe o que é mock, aguarde que será explicado mais a frente) possibilitam isso, mas esse é um forte indício de alto acoplamento. Para testar esse método de uma forma mais elegante, em vez de usar essas opções apresentadas, será necessário refatorar o nosso controller: em vez de procurarmos o que queremos, vamos inverter isso e receber a dependência no construtor. Isso é, vamos aplicar o princípio de inversão de controle através da injeção de dependências, como na Listagem 4. Para essa mudança ser possível, o método envia () da classe EnviadorDe apresentada na Listagem 2 precisará deixar de ser estático. Será que agora podemos testar facilmente nossa classe? NovoUsuarioController novousuario = new NovoUsuarioController(); // que verificações faço aqui? Listagem 4. Removendo acoplamento com EnviadorDe . private EnviadorDe enviadorde ; public NovoUsuarioController(EnviadorDe enviadorde ) { this.enviadorde = enviadorde ; enviadorde .envia (usuario.get ()); 33

3 Utilizando Mocks Uma solução eficaz para o teste dessa nova versão da classe é o uso de mock objects, que nos permite isolar os testes das classes de um sistema de forma simples. Como muitos já conhecem, um mock object é um objeto falso criado com base em uma estrutura definida, que pode simular comportamentos de dependências e verificar a corretude na interação da classe testada com a mesma. No caso do exemplo, a classe NovoUsuarioController depende diretamente da classe EnviadorDe para cumprir suas responsabilidades. Ao invés de utilizarmos a classe EnviadorDe , usaremos outra, que finge fazer o que essa dependência deveria fazer, porém é mais simples e fácil de ser usada no ambiente de testes, por termos controle sobre ela. O código atual da classe NovoUsuarioController já está com um design bem melhor, que nos possibilita injetar um mock no lugar da dependência. Para fazer isso, precisaríamos estender a classe EnviadorDe e reescrever o método envia (), de tal forma que ele apenas fingisse enviar um . Essa invocação do método também seria registrada para depois ser usada na asserção do teste. Sendo assim, essa nova classe-filha seria utilizada para os testes. Apesar dessa solução funcionar, podemos usar algo mais elegante para evoluir o design da aplicação. Devemos refatorar: agora a classe NovoUsuarioController passará a receber como dependência (Listagem 6) uma referência para alguém que implemente uma nova interface chamada Enviador (Listagem 5) que possui um único método envia () declarado (o que pode ser feito através de uma IDE como o Eclipse, que oferece a refatoração automatizada Extract Interface ). Agora, durante o teste (Listagem 8), passaríamos um objeto especial, da classe Enviador Dummy, que implementa a interface Enviador e simula um envio de (Listagem 7). Esse dummy é um mock menos inteligente, já que não verifica e nem realiza nenhuma operação. No teste, basta fazer uma asserção para verificar se o destinatário do que foi utilizado dentro do mock é igual ao do usuário que está sendo cadastrado. Listagem 5. Interface Enviador. public interface Enviador { void envia (string para); Listagem 6. Troca da dependência da classe Enviador para a interface Enviador. private Enviador enviadorde ; public NovoUsuarioController(Enviador enviadorde ) { this.enviadorde = enviadorde ; enviadorde .envia (usuario.get ()); Listagem 7. Criação do EnviadorDe Dummy. public class EnviadorDe Dummy implements Enviador { private String enviadopara; public void envia (string para) { // simulação de envio de this.enviadopara = para; public String getenviadopara() { return this.enviadopara; Listagem 8. Teste usando um mock object. EnviadorDe Dummy mock = new EnviadorDe Dummy(); NovoUsuario novousuario = new NovoUsuario(mock); Assert.assertEquals(usuario.get (), mock.getenviadopara()); Apesar de ter sido fácil criar o mock para a interface Enviador como um objeto bobo (dummy object), muitas vezes a dependência pode ter métodos que são difíceis de serem simulados, pois retornam outros objetos, por exemplo. Outra dificuldade que podemos enfrentar é quando a unidade que estamos testando possui muitas dependências, o que acarretaria na criação de mocks para cada uma delas. Ao enfrentarmos estas situações uma boa opção seria a utilização de ferramentas que criam em tempo de execução objetos mockados para serem utilizados e nos testes de unidade. Criação automatizada de mocks Um dos frameworks que vem se destacando no mercado é o Mockito ( por ser simples e de fácil entendimento, considerado uma evolução em relação às outras alternativas. Utilizaremos ele para mockar nossa dependências, mas, como visto na edição 31 da Mundoj, o Jmock é uma outra excelente opção Para utilizarmos o mockito, basta fazer o download no site (ver referências) e colocar o mockito-all-x.x.x.jar no classpath da aplicação. O código de teste com o uso do Mockito está apresentado na Listagem

4 Listagem 9. Mock de dependências com mockito. Criar mocks utilizando frameworks do tipo Mockito torna-se uma tarefa muito simples e que pode nos levar a acreditar que nosso design está simples e extensível. Porém, na maioria das vezes, isso indica um cenário em que o código está muito acoplado e ruim, um sinal de que a unidade que estamos testando talvez esteja fazendo mais do que deveria por ter muitas dependências. No caso de encontrar esse tipo de problema, o melhor a se fazer é refatorar essa classe de forma a diminuir suas dependências, separando as responsabilidades e testando cada uma das novas classes individualmente. Enviador mock = Mockito.mock(Enviador.class); NovoUsuarioController novousuario = new NovoUsuarioController(mock); Mockito.verify(mock).envia (usuario.get ()); E se usássemos TDD? Como sabemos, Test-Driven Development é o nome dado a prática de criar os testes antes mesmo de escrevermos o código que queremos que seja testado. Muitos citam que sua grande vantagem é que dessa forma não teremos código que não possua teste, mas essa realmente não é a única vantagem. O primeiro passo para utilizar o Mockito é pedir para que ele crie através do seu método principal, o método mock(), um objeto mockado a partir de uma interface ou classe. Em nossos testes precisamos de um mock da interface Enviador, que é obtida invocando Mockito.mock(Enviador.class). Uma das principais características do Mockito é que quando criamos algum mock não precisamos definir antecipadamente quais métodos serão invocados nele, como seria feito se utilizásemos um stub. Em seguida, basta passarmos a dependência para a classe NovoUsuarioController e depois da execução do método fazemos a verificação para saber quais métodos do mock foram chamados no método adiciona(), comprovando que o método realmente invoca a funcionalidade para envio de quando o cadastro é finalizado. Isso é feito utilizando o método verify() da classe Mockito. No teste da Listagem 9 verificamos se o método envia () foi invocado recebendo como parâmetro a propriedade do objeto Usuario que está sendo cadastrado. O Mockito pode ajudar em muitas tarefas durante o desenvolvimento de testes de unidade. Considere que o cenário de teste em que método envia- () deve retornar uma exceção quando o de destino indicado for inválido. Um teste utilizando Mockito que verifica esse comportamento está representado na Listagem 10. No exemplo, o comportamento esperado para a classe NovoUsuarioController seria enviar uma exceção do tipo IllegalArgumentException Listagem 10. Teste mais avançado utilizando mockito. (expected = IllegalArgumentException.class) public void retornaexcecaoquando forinvalido() { usuario.set ( lucas.souza#caelum.com.br ); usuario.setusuario( lucas.souza ); usuario.setsenha( ); Enviador mock = Mockito.mock(Enviador.class); Mockito.doThrow(new IllegalArgumentException()).when(mock).envia (usuario.get ()); NovoUsuarioController novousuario = new NovoUsuarioController(mock); A vantagem de fazer os testes primeiro é que não precisaríamos repensar todo o design da nossa aplicação como exemplificado no exemplo deste artigo. Se tivéssemos guiado nosso desenvolvimento a partir dos testes, terminaríamos com um design mais simples, abstrações mais bem definidas e códigos mais reutilizáveis. E por consequência ganharíamos a confiança no código implementado a partir dos próprios testes. No artigo, para obter um design elegante e simples, várias vezes tivemos que refatorar o código e o teste. Utilizando TDD também faríamos refatorações, que é uma ótima prática, mas com certeza chegaríamos no design ideal bem mais facilmente do que fazendo os testes depois. Por que esse design melhorado já apareceria desde cedo? Vamos ilustrar isso escrevendo o teste para a classe NovoUsuarioController, considerando que ainda não implementamos nem essa classe, nem o enviador de . A Listagem 11 esboça o início dessa situação. Listagem 11. Mock de dependências com mockito. NovoUsuarioController novousuario = new NovoUsuarioController(); // aqui preciso testar se o foi enviado. Como? Escrevendo o teste dessa Listagem 11, logo perceberíamos duas coisas: precisamos criar a classe NovoUsuarioController e necessitamos que ela tenha um método que adiciona um usuário. Isso já mostra como o teste guia também a criação de como a classe interage com seus clientes. Depois disso, como verificar se o foi enviado? De alguma forma precisamos de um objeto (um mock?) que vá dizer se foi tentado enviar um para o paulo.silveira@caelum.com.br. Esse objeto de alguma forma tem de estar relacionado com o NovoUsuarioController. Para fazer isso, passaremos esse objeto via construtor (poderia ser de outra forma, 35

5 como usando um método setter) para o controller. A fim de tornar mais fácil o processo de criar um mock para esse objeto, será criada uma interface para abstrair seu comportamento. Dado esse raciocínio, cairíamos diretamente num código muito semelhante ao da Listagem 9. Outra prova de como o TDD auxilia no design é que dificilmente teríamos usado o DaoFactory com métodos estáticos, pois perceberíamos que seria complicado conseguir simular essa parte na hora de criar um teste que verificasse se o DAO foi acionado ao adicionar um novo usuário. Normalmente percebe-se que é importante tornar o código mais desacoplado, por exemplo, recebendo no construtor o UsuarioDAO. Ou talvez outra solução, como recebê-lo através de um setter ou ainda utilizando uma busca em um registro. Porém, a injeção via construtor acaba sendo uma alternativa muito popular e demonstra vantagens em relação a outras abordagens de inversão de controle, já que isso impede que o objeto seja instanciado e fique num estado inconsistente, sem ter suas dependências preparadas. São por esses motivos que algumas pessoas chegam até a se referir ao TDD como Test-Driven Design. TDD e injeção de dependências Injeção de dependências é uma maneira de diminuir acoplamento, na qual a classe recebe suas dependências externamente, através de métodos ou construtores, ao invés de criá-las de forma interna. Evitar que classes busquem suas dependências torna possível construirmos testes de unidade que foquem apenas no comportamento da classe que está sendo testada, ou seja, qualquer mudança que ocorra em alguma dependência da classe testada não deveria impactar no teste. Com TDD alcançamos isso de maneira mais fácil, porque quando vamos escrever os testes percebemos a necessidade de torná-los de fato um teste de unidade. Por exemplo, no caso do teste da adição de um novo usuário perceberíamos prematuramente que o envio de não deveria ser um envio real que utiliza um SMTP de verdade. No exemplo de teste apresentado, a classe NovoUsuarioController deve ser independente do comportamento da classe EnviadorDe . Isso nos levaria a perceber a necessidade de desacoplar o código através da injeção da dependência. Considerações finais O teste de unidade já se provou essencial, mas sabemos como é difícil criar esses testes se o código já está pronto: ele pode estar (e provavelmente está) muito acoplado, sendo difícil evitar que os testes de unidade se tornem de integração. Muitos desistem de criar testes por essa dificuldade inicial, ao tentar criar testes para código já existente. O uso do TDD, além de trazer o benefício de garantir que você vai ter uma boa cobertura de testes e só vai escrever o que realmente é necessário, implica em um design mais desacoplado. Isso pode ser explicado por um motivo muito simples: sem design desacoplado, criar um teste de unidade é bastante difícil. Logo, o TDD de certa maneira o força a ir em direção a inversão de controle, muitas vezes através de injeção de dependências, de uma maneira clara e natural. Referências Independentemente se usamos algum framework de injeção de dependências (Spring, Guice, Pico etc.) no ambiente de produção, nos testes é importante utilizarmos essa práticaa para que os objetos mockados possam substituir as dependências, isolando assim a unidade que estamos testando. 36