Test Driven Development By Example

Li recentemente o livro TDD By Example. É um livro excelente, uma introdução à mentalidade do TDD. Talvez falte algo mais parecido com o dia-a-dia dos projetos reais, mas não é esse o foco do livro.

O nome do livro é “By Example” porque há dois exemplos no livro, que tem o mesmo “jeitão” de katas:

  • o primeiro problema é a soma de moedas diferentes, no caso francos suíços e dólares. O primeiro exemplo é implementado em Java. Kent Beck vai mostrando como ele resolveria o problema desde o começo e toma rumos surpreendentes por duas vezes :
    • Kent começa com uma classe Dólar. Quando há a necessidade de mais uma moeda, ele cria a classe Moeda, torna Dólar subclasse de Moeda e cria a subclasses Franco. Mais pra frente, ele remove as duas subclasses (Dólar e Franco) e as diferencia apenas como atributos da classe Moeda. É muito estranho remover classes, mas depois descobri que “minimizar classes e métodos” é uma das regras do design emergente do XP. O mais incrível é que ter apenas uma classes Moeda realmente facilita o trabalho mais pra frente.
    • Para fazer a conversão em si, Kent evita um código procedural cheio de ifs.  A responsabilidade de fazer a conversão dos valores em uma mesma moeda é de uma classe chamada Banco. Kent discute uma abordagem que usa como metáfora uma carteira. Mas na implementação do livro, ele usa a idéia de expressões, que é muito mais flexível.
  • o segundo problema é a criação de um framework de test unitário usando TDD. Muito doido, não? Esse exemplo é dado em Python.

Segui o código da primeira parte do livro, “The Money Example” e coloquei o código no meu github: http://github.com/alexandreaquiles/the_money_example

Na última parte do livro o cara discute sobre a filosofia de TDD, sobre design patterns, refactoring, etc… Essa talvez seja a parte mais rica do livro.

Kent sugere é que você comece o dia com uma lista do que o seu código deve fazer. Você deve ir criando testes que exercitem os requisitos dessa lista e, à medida que você descobre novas responsabilidades para o seu código, você insere novos itens na lista. A lista pode ser de papel mesmo. O importante é manter um registro dos pensamentos que surgem enquanto você codifica, para que eles não “fujam”. Manter essa lista é ajuda a pensar no seu design.

Outra coisa muito importante no TDD é fazer as coisas em baby steps, ou passos de bebê. A idéia é fazer as coisas aos poucos, um pouco de testes e um pouco de código de cada vez. Isso faz com que você se perca menos e foque mais naquela parte do problema que você está resolvendo. Além disso, se um teste que estava passando passa a falhar, você sabe exatamente o que você estava fazendo, evitando um bom tempo de debug.

Uma das frases mais interessantes dessa terceira parte do livro diz respeito a, quando você tem um teste falhando, como você deve implementar:

Se você sabe o que escrever, use a Implementação Óbvia. Se você não sabe o que escrever, use uma Implementação Simulada (fake it). Se o design correto não está claro, Triangule. Se você ainda não souber o que escrever, pare tudo e vá dar uma relaxada.

Anúncios