Screencast: TDD em Ação

Conforme prometido, aqui está o screencast de um exemplo real de TDD. O vídeo tem aproximadamente 14 minutos (expremidos heroicamente em menos de 8MB), e trata um pouco dos seguintes assuntos:

• Organização dos testes no eclipse
• O fluxo de trabalho do TDD (vermelho-verde)
• Desenvolvimento incremental (baby steps)
• Implementar a solução mais simples que funcione (Fake It)
• Como refatorar com maior segurança graças aos testes
• Criação de testes para tratamento de exceções

Tentei usar um exercício extremamente simples para poder me focar mais na maneira de se raciocinar usando TDD. Como este é meu primeiro screencast acredito que ele está longe da perfeição (o áudio teve que ser substituído por legendas, por exemplo), mas espero que seja útil mesmo assim 🙂

Assista o screencast TDD em Ação

Minicurso de TDD

Antes tarde do que nunca, estou disponibilizando os slides do Minicurso de TDD que ministrei no Sun Tech Days em Florianópolis. São apenas 10 slides, mas que podem ajudar pra quem está aprendendo ou pensando em apresentar alguma coisa sobre o tema.

O último slide propõe um exercício que foi resolvido na hora com ajuda da platéia. Já transformei a resolução dele num screencast e estou finalizando sua edição para postar aqui no blog também. Enquanto este não está pronto, você pode baixar os slides do minicurso.

Métrica simples e útil? Use RCT

RCT, ou Relação Código-Teste (Code To Test Ratio) é uma métrica extremamente simples, que permite verificar como andam os testes durante o projeto:

RCT = Linhas de Teste / Linhas de Código

Normalmente o valor obtido varia entre 0, quando não existe nenhum teste, e 1,5, quando se escreve 50% de linhas de teste a mais do que linhas de código. Até hoje não vi muitos projetos passarem deste valor, mas já é bastante normal ver projetos nesta faixa. Veja alguns exemplos no Code to Test Ratio Showdown.

O interessante desta métrica é que ela pode servir para acompanhar a adoção de TDD e verificar se os testes não estão sendo deixados de lado. Por isso ela deve ser coletada periodicamente, e deve-se buscar um valor que varie muito pouco quando a utilização de testes estiver satisfatória.

Atualmente estou trabalhando num projeto onde a RCT é 1.3. Em projetos Ruby on Rails a RCT é facimente obtido via rake stats:

Code LOC: 549 Test LOC: 690 Code to Test Ratio: 1:1.3

O projeto ainda está no começo (pouco mais de 500 linhas de código), mas o meu objetivo é que minha RCT nunca baixe de 1.3, e se possível alcance 1.4 quando eu passar a fazer mais testes de integração 🙂

E no seu projeto, quantas linhas de teste você gera para cada linha de código? Se você obter a RCT do seu projeto, divulgue-a nos comentários!

TDD on Rails

O Nando Vieira postou o primeiro do que parece ser uma série de posts sobre Test-Driven Development no Ruby On Rails.

O primeiro episódio trata dos testes de unidade e como testar os Models da aplicação.

Vale a pena conferir.

XP Checklist #2: Desenvolvimento Orientado a Testes

Visão geral do Desenvolvimento Orientado a Testes:

Para extrair o máximo dos testes durante o desenvolvimento, devemos pensar neles como uma ferramenta de comunicação e aprendizado contínuo. Portanto seu foco deve ir além da verificação e pautar o desenvolvimento como um todo.

Objetivo:

Ajudar o desenvolvimento e aumentar a confiança para fazer qualquer modificação no sistema.

Participantes:

• Cliente
• Equipe de Desenvolvimento

Pontos principais:

• Todos os testes devem ser automatizados.
• Os testes são escritos antes mesmo da funcionalidade existir
• Uma User Story está pronta quando todos os Testes de Aceitação passam e não se consegue imaginar mais testes para ela
• O desenvolvimento é feito em pequenos incrementos (“baby steps”)
• O projeto da implementação deve favorecer a confecção de testes
• O Cliente escreve testes de aceitação com ajuda da Equipe de Desenvolvimento. Se isso não é possível é interessante que ele ao menos valide o testes que a Equipe de Desenvolvimento criar
• A depuração de código deve ser substituída por testes sempre que possível
• Busca-se que todos os testes passem sempre. Se algo não está funcionando isto deve ser do conhecimento do Cliente.
• Um novo teste deve ser escrito quando for preciso reproduzir um erro ou esclarecer melhor uma funcionalidade.

Resultados esperados:

• O cliente terá maior confiança que as User Stories que ele definiu estão implementadas
• A equipe terá maior confiança para fazer as mudanças que o cliente pedirá no futuro
• Existirá sempre uma especificação atualizada, representada pelos testes
• O design do software será favorecido pela simplicidade
• A ocorrência de erros diminuirá

Atualização:
(11/05/2007) Novos itens foram adicionados nos Resultados Esperados (agradecimentos ao ViniciusAC)

Por que desenvolvimento ágil compensa?

Se você quer a resposta simplificada:

Desenvolvimento ágil compensa porque ele faz com que o software gere valor de negócio durante toda sua existência, enquanto no modelo tradicional a tendência é que depois da versão 1.0 este valor apenas diminua.

Se quiser uma explicação melhor:

UML vs TDD

Aqui estão os principais benefícios que as pessoas buscam com UML, e uma análise resumida de como é possível (ou não) obtê-los com Test-Driven Development (TDD):

Análise prévia do problema

Se você precisa explorar o que o sistema deve fazer exatamente, o que pode ser melhor do que trabalhar como se ele já existisse? Os testes em TDD permitem isso, e de quebra ainda permitem validar o que foi implementado posteriormente. Ponto para TDD neste quesito.

Resultado parcial: UML 0 x 1 TDD

Reutilização de código

Aqui as duas abordagens trabalham de maneira muito distintas. Enquanto em UML tentamos identificar os pontos de reutilização antes, em TDD você deixa que estes pontos apareçam através de duplicações no código, que são removidos e transformados em componentes reutilizáveis com apoio dos testes automatizados. Para não entrar numa discussão sobre BDUF x Agile por enquanto, vamos declarar um empate.

Resultado parcial: UML 1 x 2 TDD

Linguagem unificada para especificação de sistemas

Como o princípio do TDD é especificar o sistema através de testes executáveis, ainda não existe uma ferramenta genérica que seja aplicável para qualquer sistema. Isto se deve ao fato que a execução destes testes automatizados geralmente depende da tecnologia que o sistema utiliza.

Ferramentas como FitNesse fornecem uma linguagem única para escrever testes independente da tecnologia do sistema, porém ainda deixam a desejar no que trata da execução destes testes.

Já para sistemas web, no entanto, o Selenium já desponta como ferramenta que se aplica a qualquer sistema que trabalhe com apresentação em HTML (independente da linguagem utilizada no servidor), o que constitui um cenário bastante abrangente hoje em dia.

Em resumo, se o que você busca é uma linguagem genérica, UML leva uma certa vantagem.

Resultado parcial: UML 2 x 2 TDD

Aumento na qualidade

Ambas as abordagens (se bem utilizadas) apóiam a qualidade, mas nenhuma delas a garante. Então temos mais um empate.

Resultado parcial: UML 3 x 3 TDD

Ferramenta de aprendizado

Não existe diagrama que substitua o que é ver uma determinada parte do sistema funcionando. E com TDD é possível aprender tanto o que o sistema faz (testes funcionais ou de aceitação) quanto como ele funciona internamente (testes de integração, de unidade, de desempenho). Mais um ponto para TDD.

Resultado parcial: UML 3 x 4 TDD

Facilidade na manutenção

Fazer uma mudança no sistema em UML implica em atualizar os diagramas e aplicar estas mudanças no código. Em TDD mudanças são representadas por novos testes automatizados, enquanto os testes já existentes colaboram para analisar o impacto desta alteração no resto do sistema. A vantagem de TDD neste caso é que é possível ver se o sistema está 100% funcionando por inteiro, o tempo todo. Já com UML isso só pode ser feito manualmente ou com apoio de ferramentas de rastreabilidade.

Resultado final: UML 3 x 5 TDD

Conclusão

Quem esperava uma vitória fácil de TDD deve ter ficado decepcionado. A questão é que UML tem seu valor, ainda mais se considerarmos que a maioria dos softwares ainda é construída com ciclos em cascata ou espiral. A minha idéia aqui foi apenas apresentar uma alternativa ao uso de UML e levantar a questão: será que UML é a melhor solução?

A minha parte eu já fiz, lançando a questão. Agora só me resta esperar a resposta dos defensores da UML 😉