Usando Test-driven Development – Semana 1

Hoje completei uma semana utilizando TDD (Desenvolvimento orientado a testes) em tempo integral. Quando eu digo ‘tempo integral’, entenda como ‘usando do jeito certo’, criando testes primeiro para depois programar a funcionalidade.Com a ajuda de Kent Beck (Test-Driven Development by Example), e dando várias e boas cabeçadas, consegui juntar uma listinha de itens para ajudar os próximos corajosos que resolverem se aventurar nesse modo de desenvolver software.

  • Crie uma história
    Esse é o início de tudo. Provavelmente a história já existe e chega na forma de um requisito. Você pode definir o formato que ela vai ter, ou o projeto já deve ter algum padrão. Nesse projeto eu uso a seguinte estrutura:
    Quando fulano faz tal ação, acontece tal resultado.
    Se você está programando um software de PDV, por exemplo, ela pode ser traduzida como ‘Quando o operador de caixa ler o código de barras, eu devo exibir o nome do produto e o preço‘.
    Nada de extraordinário ou de complicado. Quem já XP alguma vez na vida deve conhecer por User Story.
  • Simplifique
    Provavelmente você não vai conseguir resolver com meia dúzia de linhas de código. Então comece com algo simples, sem perder o foco e sem esquecer do problema que você tem para resolver.
    Usando o exemplo acima, nós logo notamos que o código de barras vem de algum lugar, que as informações sobre o produto estão em outro lugar, e que alguém vai utilizar o resultado disso.
    Com isso, o problema maior se torna três problemas menores e mais simples de resolver.
  • Mantenha uma lista de itens a fazer
    Essa veio direto do livro do Beck, e que eu apanhei por não ter feito. Crie uma listinha, num pedaço de papel mesmo, com os itens que forem aparecendo, as dúvidas que você tiver e os testes que você pretende implementar para aquele problema menor que você resolveu atacar.
    Lembre-se de manter a simplicidade e escrever numa linguagem que você possa lembrar no dia seguinte. No meu caso, tive um fim de semana no meio do desenvolvimento.
  • Um teste por vez
    Outro erro que cometi: criar vários testes de uma vez.
    De repente eu tinha três testes em vermelho, e só podia resolver um por vez. Isso aumenta o nível de stress e dificulta a visualização do problema.
    Nesse caso específico eu tinha um objeto sendo manipulado no método testado, e ao dar return, eu criava uma instância nova e limpa ao invés de devolver aquela que já estava tratada.
    Mais ou menos isso:

    MeuObjeto fazAlgumaCoisa(Valor parametro){
    MeuObjeto retorno = new MeuObjeto();
    retorno.qualquerCoisa(parametro);
    return new MeuObjeto();
    }

    Triste…

  • Um passo por vez
    Criar um teste por vez nos leva a dar pequenos passos, um de cada vez, conforme seu código vai evoluindo. Claro que um pequeno passo para um Martin Fowler pode ser uma maratona para mim.
  • Não se preocupe com desempenho
    Pelo menos num primeiro momento. Otimização sem critérios pode ser uma excelente fonte de bugs aparentemente sem sentido.
  • Seja realista
    Pode apostar: se você nunca usou TDD, você vai perder mais tempo e ficar menos produtivo no início. Todo aprendizado é assim, e com TDD não seria diferente. Então, use o bom senso, se você tem uma tarefa para entregar amanhã cedo, não invente. Não tente usar TDD pela primeira vez na vida em um projeto atrasado e com cronograma estourado. No final das contas você vai ficar com fama de irresponsável, de improdutivo e o TDD vai levar a culpa pelo fracasso do projeto.
    Após o quarto dia eu comecei a sentir a diferença. O código passou a fluir mais rápido, e eu estava confiante de poder prosseguir sem medo de estar ferrando com o resto da aplicação.
    Claro que o fato de você estar criando testes torna o seu código muito mais confiável e menos sujeito a erros, mas eu não recomendo que você considere-o 100% correto e livre de bugs, pelo menos no início. Auto-crítica costuma ser uma virtude nesse caso.
  • E, de novo, simplifique.
    Como dizia um professor que tive, ‘não invente, faça o básico‘. O importante, num primeiro momento, é entregar software funcional. O teste serve, antes de mais nada, para verificar que seu código recebe uma entrada e devolve a saída prevista. Não perca tempo reinventando a roda e tentando parecer sagaz aos olhos de outros programadores. Pensar simples, ao contrário do que parece, é uma das coisas mais difíceis de se aprender.

Essas são as minhas impressões. Nada impede de escrever sobre a segunda semana e dizer algo oposto ao que está em algum ponto daqui. O aprendizado consiste em aprender coisas novas e corrigir falhas antigas.

😉

Anúncios

2 respostas para Usando Test-driven Development – Semana 1

  1. Pedreiro disse:

    Sou meio bruto nesse caso, quando tenho um projeto para entregar, eu programo linha a linha e sempre cumpro o prazo, o meu problema é implementação, isso fode ca vida dum programador.

    Parece pastelaria aqui, meus prazos são de semanas e muitas vezes dias. ¬¬ A otimização sempre fica para uma segunda versão.

  2. Kekone disse:

    Muito bom para estimular quem nunca se aventurou neste terreno.

    Espero que continue com o “walkthrough”

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: