Modelo TDD Globo.com
É possível definirmos um modelo de TDD para a Globo.com? É claro que dentro da empresa temos diferentes sistemas, implementados com linguagens distintas, com arquiteturas que às vezes não tem nenhuma semelhança, mas acho que se chegarmos a um consenso sobre um ou mais modelos podemos facilitar a adoção dessa metodologia de desenvolvimento.
Aqui no grupo DesenvAplicativos2, estamos com algumas dúvidas e eu mesmo, tenho vários questionamento a fazer. Não tenho muita experiência com TDD e confesso que ainda não tive tempo pra estudar o assunto e formar uma opinião. O tempo de estudo fora do trabalho está todo dedicado ao mestrado.
O primeiro questionamento é em relação a testes unitários. Como implementá-los de acordo com a realidade de arquitetura das nossa aplicações? Já lí um artigo que falava de TDD onde o autor usava como exemplo uma função que fazia a divisão entre dois números. Achei esse artigo muito interessante por que ele ia melhorando a implementação do método conforme os testes iam falhando. Mas esse exemplo, como muitos que aparecem na internet, utilizam classes simples, com métodos estáticos, o que é bem diferente do que implementamos no nosso dia-a-dia. As nossas aplicações usam uma arquitetura separada em camadas, numa variação do padrão Model 2. Poderíamos implementar JUnits que chamassem diretamente a camada de dados, ou que chamassem a camada de negócios, ou mesmo as actions. Uma coisa parece certa, quanto mais perto da camada client, mais garantimos maior cobertura de código. Confere?
Outra dúvida: se fizermos um JUnit que chama a camada de negócio, esse teste não estaria deixando de ser unitário, já que a camada de negócios depende da camada de dados?
Uma opção na implementação dos testes é o uso de mock objects. Cheguei a conversar com Nunes na época em que ele ainda estava aqui e torci um pouco o nariz para essa prática. Ele me passou um link que achei interessante ( http://www.martinfowler.com/articles/mocksArentStubs.html ). Acho que o uso de mocks implica na quebra de um dos pilares da orientação a objetos que é o encapsulamento. Pelo menos no exemplo que ele fez comigo eu tive essa impressão.
A informação que tenho é que a equipe de webmedia já adota TDD a algum tempo e faz isso com sucesso. Podemos então escolher uma dentre duas estratégias: ou adotamos o modelo que webmedia está utilizando e evoluimos a partir daí, ou colocamos o assunto em discussão como estou fazendo agora para chegarmos a um consenso e adotarmos como modelo.
Existem vários outros assuntos relacionados a testes que pretendo discutir mas queria deixar o escopo desse post fechado em testes unitários.
A discussão está aberta para compartilharmos o conhecimento.
January 15th, 2008 at 7:23 pm
Oi Claudio,
Em primeiro lugar, acho que temos que separar duas coisas:
-> Testes unitários = testes que testam apenas um método ou uma pequena porção de código. Neste caso, todas as dependências devem ser isoladas, seja através de mocks ou de objetos “fake” (um objeto stub que implementa uma determinada interface).
-> Testes de integração = testes que testam a integração entre diversos componentes ou camadas de uma aplicação. Por exemplo, um teste que acessa um ServiceLayer, que por sua vez acessa um DAO e que por sua vez acessa um banco de dados não é unitário. Ele está na verdade testando a integração entre todos esses componentes.
Falando de maneira simplória, a idéia do teste unitário é que quando há um erro, você sabe _exatamente_ onde ele está: no método que você está testando. Neste tipo de teste, se você não “mockar” todas as dependências, você pode não saber exatamente em que camada/componente o erro está. O erro pode nem mesmo existir, poderia ser um falha na conexão com o banco de dados, por exemplo.
Outro problema é que se você não mockar as dependências você pode acabar precisando de uma infraestrutura muito grande para os testes rodarem. Por exemplo, como você testaria um servlet se você não mockasse todas as dependências? Você precisaria de um servlet “deployed” num servlet conteiner para fazer a execução, e mesmo assim se o teste falhasse você não saberia exatamente a causa: poderia ser o web.xml mal configurado, espaço em disco que acabou, e por aí vai, sem contar que você precisaria fazer uma requisição http para que o código fosse executado.
Testes com dependências isoladas nem sempre são simples de serem feitos. No entanto, algumas técnicas e cuidados especiais podem ser adotados para facilitar sua implementação, como inversão de controle e injeção de dependência, evitar o uso de singletons, evitar métodos estáticos e etc.
No ano passado eu tinha pensado em fazer um techtalk que seria um workshop sobre TDD/testes unitários. Se a galera achar interessante eu me disponho a fazê-lo sem problemas. Seria legal também para termos a oportunidade de discutir e tirar todas essas dúvidas, já que escrever um testamento aqui não é lá muito prático
[ ]s, Guilherme
January 16th, 2008 at 2:28 pm
Acho a idéia do Techtalk bastante interessante. Podemos até colher os questionamento que aparecerem aqui pra colocar na apresentação.
Ok, entendi as suas afirmações, mas continuo com algumas dúvidas:
Qual é o critério que devemos usar para implementar testes unitários? Todas as classes do sistema (Actions, BOs, DAO, Helpers, etc) terão que ter um JUnit correspondente?
Devemos selecionar algumas que são mais complexas e esquecer o resto?
Como vocês fazem aí em Webmedia?
[]s, Cláudio Luz
January 19th, 2008 at 2:55 pm
Cláudio, veja esse post: “http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1243962,00.html?bucket=ETA&topic=306112″. Apresenta bem o problemas das dependências. A “unidade” (do termo unitário) deve ser definida de acordo com a sua necessidade (o que algumas vezes é difícil descobrir), sempre levando em conta o isolamento das dependências de modo que você possa encontrar mais facilmente os problemas.
January 21st, 2008 at 4:32 pm
E sobre BDD? Para código cliente, jsUnit? jsMock? Seria bom compartilhar experiência com desenvolvimento de testes unitários.