Tornando TDD Simples: Problemas e Soluções para Implementadores

Postado por Mark Levison , traduzido por Wagner R. Santos em 02 Fev 2009

Seções

Processos e Práticas,

Arquitetura e Design

Tópicos

Colaboração ,

Agile ,

Metodologias ,

Técnicas Ágeis

Tags

XP ,

Testes ,

TDD

Eu tenho visto um grande número de times em nossa empresa se matando para adotar um Desenvolvimento Orientado a Testes (Test Driven Developement -TDD)[1]. Ocasionalmente um ou dois desenvolvedores obtém sucesso sem ajuda alguma, mas a maioria não. Para melhor compreender o problema fiz uma série de pesquisas com os membros dos times e cheguei a conclusão que mesmo após o treinamento em sala de aula, ainda havia muito a ser feito. Esta estratégia planejada foi desenhada para ajudar qualquer um que queira implementar TDD dentro de uma empresa, porém alguns destes problemas e idéias são aplicados somente em empresas de média e larga escala.

Minha pesquisa com os membros do time (onde todos receberam treinamento) revelou estes bloqueios: 

 

• Pessoas acham difícil aplicar TDD em seu desenvolvimento, quando elas não possuem muita experiência com isto.
   
• O Treinamento em TDD tem sido muito focado em problemas mais simples do que na vida real.
   
• É preciso mais tempo para experimentar e testar sem a pressão corriqueira de liberar o software em uma data específica.
   
• Linguagens utilizadas no mundo real, como Visual Basic ou JavaScript, nunca são utilizadas como exemplos em documentação de testes unitários ou exercícios em classe de aula.
   
• A média de código é totalmente de código legado, e nenhum treinamento foi dado sobre como trabalhar com este tipo de código.
   
• Nunca a tempo de aprender – existe sempre (artificial) uma pressão para entregar o produto o mais rápido, de forma que não há tempo para melhorar o código.

Problemas Reais

Com todos estes sintomas, quais são os problemas reais?

Test Driven Development pode ser muito difícil de aprender. A fase de aprendizagem (a duração de tempo até que se torne um hábito latente) tipicamente dura de dois a quatro meses, tempo cuja produtividade é reduzida [2]. Geralmente os benefícios serão óbvios e a técnica é geralmente auto sustentável, mas a questão é: como chegar lá? Muitos desenvolvedores desistem após somente alguns dias.

A maioria das estratégias de adoção que tenho visto foca em treinamento em sala de aula (ou e-learning) e mentoring um-a-um. Quando bem feito, estas são ferramentas excelentes e pode fazer parte de uma solução, mas eu acho que é necessário mais.

 

Treinamento em sala de aula sofre por conta de dois problemas chave: os exemplos são muito fáceis e não se relacionam com problemas reais; e não há muita chance de praticar.

 

Treinamento online (tanto Object Mentor e Industrial Logic, entre outras, tem benefícios), tem a vantagem de ir mais a fundo. Entretanto, ainda assim não existe a chance de praticar. Em compensação, estes cursos são normalmente realizados sem a interação com outros estudantes. Ouvir questionamentos de outros estudantes e colegas de classe geralmente ajudam na compreensão.

 

Mentoring um-a-um não escala além de poucos membros de um time. Isto é especialmente difícil em um ambiente corporativo de larga escala onde existem somente alguns poucos especialistas e centenas ou milhares de pessoas precisando de ajuda.

 

Livros são uma opção excelente mas somente alguns desenvolvedores  gostam de ler livros a respeito de seu trabalho, e mesmo aqueles que se propõe a aprender TDD desta maneira, tem dificuldades. Como em cursos online, o problema é aprender por sua conta e risco.

 

Finalmente: código legado torna um problema que já é difícil ainda mais duro. Desenvolvedores certamente perguntam a seguinte questão: “Como eu faço para testar estes objetos altamente acoplados? Este código é complicado, como eu testo este algoritmo?”

Uma Abordagem

Então, o que funciona? As abordagens anteriores sofrem por duas causas chave: falta de profundidade e falta de colaboração. Uma estratégia completa irá apelar para múltiplos modos de aprendizagem e possui muitos elementos.

 

• Treinamento em Sala de aula - Desenvolvedores precisam de uma introdução ao TDD, e treinamento em classe de aula é ainda a melhor opção para a maioria das pessoas. O truque é entender que treinamento por si só, não irá fazer com que as pessoas adotem o TDD.
   
• Treinamento Online - Irá ajudar a absorver as idéias básicas. Se um passo nesta jornada for opcional, este poderia ser o item.
   
• Paciência - este vai tomar mais tempo do que o planejado.
   
• Medida - utilizar ferramentas para cobertura de código (ex.: Emma, Cobetura, NCover, ...) e explicar aos membros do time que medição será uma maneira de dizer se as coisas estão indo melhor ou pior.  Obviamente isto não mede a qualidade do teste e precisa ser feito com certa dosagem.
   
• Instigar Orgulho - Desenvolvedores precisam saber que código simples e claro e testes são similares, e eles precisam saber que vale a pena o esforço de produzi-lo. Bob Martin escreveu um livro chamado “Clean Code” que esclarece muito bem isto.
   
• Gerenciamento - Desenvolvedores precisam de um sinal claro da gerência que eles entendem que a transição para o TDD irá levar tempo e “diminuir” o rendimento do time[3]. Eles precisam tornar claro que eles valorizam a qualidade vs toda a falta de velocidade e o acumulo de débito técnico. A maioria dos desenvolvedores se sente pressionada para produzir, produzir e produzir. O gerenciamento terá que provavelmente repetir este entendimento mais de uma vez. Quanto mais alto for a área que este enunciado for emitido (preferivelmente executivos nível C), mais as pessoas irão escutar.

• Programação em Par - Se você se encontrar atolado e não saber para onde ir, um parceiro geralmente pode ajudar, mesmo fazer par com outro novato já pode ser um bom começo.
   
• Comunidade - Crie uma comunidade com a sua empresa (ou cidade) para compartilhar as experiências. Um local para fazer network com outras pessoas que estão aprendendo a aplicar TDD, para aprender de outros os sucessos e insucessos. Um local para ajudar a disseminar a cultura para o TDD. Uma oportunidade de compartilhar novas idéias.
   
• Coding Dojo – Um local para praticar em conjunto a solução de um pequeno problema. É um ambiente seguro, colaborativo com ênfase na exploração de um problema como um grupo e não necessariamente em como resolvê-lo.
   
• Workshops de Leitura – Um grupo de não mais que oito pessoas, para juntas regularmente se encontrarem para discutir um capítulo de algum livro.
   
• Visitas periódicas de um Coach - pode ajudar o time a voltar aos eixos, quando eles saírem do trilho e pararem de praticar TDD. Nestes casos somente emparelhando com uma ou duas pessoas pode ajudar a re-infectar todo o time.

A idéia base deste plano é o seguinte: criar conversações e aumentar a colaboração em torno do TDD. Três destas estratégias são focadas nesta área: Programação em Par, Coding Dojo e um Workshop de Leitura.

Coding Dojo

O Coding Dojo (utilizando o Formato Randori) é um evento onde um pequeno grupo de pessoas (max. 15), resolvem um problema utilizando TDD (adaptado de Danilo Sato):

• O trabalho é feito em um computador com a tela projetada para que todos vejam.
• Codificação é feita em pares
• Um membro do par troca a cada 5-10 minutos (7 funcionou bem para nós).
• Os codificadores devem explicar o que eles estão fazendo, dessa maneira a platéia entende o que está acontecendo no teclado.
• A platéia deve somente comentar sobre o design quanto os testes rodarem claramente. Quando os testes estiverem falhando a platéia deve fazer perguntas.
• Se a audiência esta confusa, o trabalho deve parar e os codificadores devem explicar o que esta acontecendo.

Por experiência eu recomendo que você escolha um problema bem pequeno para começar.

Workshop de Leitura

Para os Workshops de Leitura existe um grande número de boas opções para livros:

• em um Projeto Java: Test Driven: TDD and Acceptance TDD for Java Developers de Lasse Koskela;
• em um Projeto .NET: Test Driven Development: By Example de Kent Beck.;
• conforme você for aprendendo mais, xUnit Test Patterns: Refactoring Test Code de Gerard Meszaros.
• e se o seu código não foi desenvolvido com TDD: Working Effectively with Legacy Code de Michael Feathers.

Tipicamente, os times tentam cobrir um ou mais capítulos em uma sessão. O processo é devagar o bastante para que as pessoas possam ler fora do trabalho, sem que isto se torne um peso. Além disso, isto permite tempo suficiente para uma discussão mais aprofundada de poucos itens em um capítulo.

 

Os Benefícios de Aprender em Conjunto

Ambos workshops devem ter um fornecimento de pizza (ou uma opção de lanche mais saudável) – você está pedindo para que as pessoas gastem o seu tempo fazendo algo relacionado a trabalho, elas precisam de um incentivo. Os dois workshops podem alternar as semanas, desta maneira as pessoas não sentem que estão encurraladas em um beco. Finalmente não espere os mesmos membros de um grupo em toda sessão.

Workshops e comunidades são uma melhoria do aprendizado direcionado porque os membros do grupo estão engajados na conversação e colaboração. Como resultado nós aprendemos sobre coisas que normalmente não consideraríamos.

Tornando TDD Simples

Resumindo, aqui estão os pontos que identifiquei para criar uma estratégia de adoção de sucesso:

• Paciência, Prática, Aprofundamento
• Suporte da Gerência
• Abordagem em múltiplas vertentes
• Desenvolvedores ajudando desenvolvedores

Esta abordagem já esta em uso, trabalhando para melhorar a adoção de TDD dentro de uma grande empresa.

Agradecimentos para Lasse Koskela, Nat Pryce, Dave Nicolette e Dave Rooney por cederem seu tempo para revisar os esboços deste artigo.

 

Notas

[1] Para os propósitos deste artigo, TDD é o habito de escrever os testes antes de codificar e trabalhar em pequenos incrementos. E não produzir um grande número de testes Unitários após o código estiver escrito.

 

[2] http://tech.groups.yahoo.com/group/testdrivendevelopment/message/29461

 

[3] Produção atual irá cair - ex. o numero de estórias entregues em uma iteração irá reduzir. Entretanto uma vez que a qualidade irá melhorar logo após o inicio desta prática a queda não irá ser percebida.

 

Sobre o Autor

Mark Levison é consultor principal na Pure Agile Consulting, uma empresa de consultoria Agile e Lean que foca em ajudar seus clientes a entregar software funcional a cada duas semanas. Mark tem sido um praticante de Agile desde 2001, introduzindo uma prática de métodos Ágeis por vez em um time pequeno. Nos últimos três anos, como funcionário de uma grande ISV, ele esta sendo responsável por introduzir Scrum na empresa e fazer coaching em um número de times – incluindo o design de uma estratégia de Test Driven Development e a introdução de um número de práticas para suportar isto. Mark é Editor Agile na InfoQ e tem escrito dezenas de artigos sobre o tópico Agile. Ele também publica um blog – Notes from a Tool User. Quando não está em frente a um computador, Mark passa seu tempo com sua esposa e duas filhas.

1. Voltar ao topo

   Nota [3]

   por Clavius Tales Rocha Moreira

   A nota de número [3] a meu ver não é boa. Ela explica que haverá uma queda inicial mas que a velocidade logo será reestabelecida. Não acho que isso seja verdade. Pelo menos não foi assim aqui na empresa. Até que TDD entre no sangue e que as pessoas achem natural fazê-lo, isso leva um bom tempo. Quanto pedimos aqui na empresa que as pessoas fizessem TDD, elas logo abandonaram a prática por conta das pressões. Atenção: estou dizendo que elas abandonaram TDD, não testes unitários. Continuamos com a regra de 100% de cobertura. Ou seja, continuávamos escrevendo bom código, coberto por testes, mas não utilizávamos TDD (testes antes do código). Aqui todos foram unânimes em dizer que achavam que inicialmente se produz mais rápido sem TDD. A meu ver, a promessa da técnica é a de ser mais rápido fazendo TDD que não fazendo (neste caso, de "não fazendo", com 100% de cobertura, como já disse). Como acreditamos nisso, em que com TDD é mais rápido, mas só depois de se estar fera em TDD, resolvemos fazer da seguinte forma, para não impactar tanto na velocidade no princípio: numa parte do esforço da iteração é obrigatório fazer TDD. Pode ser um determinado horário do dia, pode ser uma quantidade determinada de turnos por semana, pode ser uma determinada quantidade de histórias por semana. À medida que a equipe for se familiarizando melhor com a técnica, aumentamos gradativamente essa parte do esforço, até que as pessoas estejam fazendo o tempo todo.

   Responder

2. Voltar ao topo

   Re: Nota [3]

   por Clavius Tales Rocha Moreira

   Só uma coisinha: o artigo é excelente. A única crítica que faço é em relação à nota [3].

   Responder

• Mais antigos >