decisões tomadas na classe CarrinhoDeCompras:
O nome do método que calculará o maior valor (maiorValor())
O nome do método que recebe um novo item (adiciona())
57
5.5. Conclusão
Casa do Código
Os parâmetros que esses métodos recebem (um Item)
O retorno do método (um double)
Todas elas são decisões de design! Se alguma dessas decisões não agradar o pro-
gramador, ele pode simplesmente mudar de ideia. O teste serve como um rascunho
para o desenvolvedor, onde ele pode experimentar as diferentes maneiras de se pro-
jetar a classe.
E o teste, na verdade, é um excelente rascunho. O teste é o primeiro cliente da
classe que está sendo criada. Ele é a primeira classe que está interagindo com ela. E
olhar para o teste com esse ponto de vista pode fazer sentido. Se está difícil testar um comportamento, é porque, muito provavelmente, sua classe está mal projetada.
Um teste no fim das contas é apenas uma classe que instancia a classe sob teste
e invoca um comportamento (método), passando um cenário determinado. Como
isso poderia ser difícil? Se está, novamente, talvez sua classe esteja muito acoplada ou seja pouco coesa (possua responsabilidades
demais). Um programador atento
percebe que está difícil escrever o teste e muda de ideia em relação ao design da
classe que está criando. Testar deve ser uma atividade fácil e prazerosa.
O próprio Michael Feathers [18] já escreveu um post sobre isso, e ele sumariza
a discussão dizendo que existe uma relação muito forte entre uma classe fácil de
testar e uma classe que está bem projetada.
Dado essa grande relação entre um código fácil de ser testado e um código de
qualidade, será difícil separar TDD de design de classes daqui para a frente. Por esse motivo, ao final do livro, encontra-se um apêndice sobre design de classes. Nele, discutimos os princípios SOLID, um conjunto de 5 boas ideias de orientação a objetos.
Esses princípios discutem basicamente as vantagens de se ter classes coesas, pouco
acopladas e simples. Caso o leitor não esteja familiarizado com estes princípios, é
sugerido que ele o leia; conhecer estes princípios facilitará a leitura dos próximos
capítulos.
5.5
Conclusão
Já vimos que os testes podem influenciar o design das classes que estamos desen-
volvendo. Ao observar o código do teste de unidade com atenção, o desenvolvedor
pode perceber problemas no projeto de classes que está criando. Problemas esses
como classes que possuem diversas responsabilidades ou que possuem muitas de-
pendências.
58
Casa do Código
Capítulo 5. TDD e Design de Classes
Ao escrever um teste de unidade para uma determinada classe, o desenvolvedor
é obrigado a passar sempre pelos mesmos passos: a escrita do cenário, a execução da
ação sob teste e, por fim, a garantia que o comportamento foi executado de acordo
com o esperado. Uma dificuldade na escrita de qualquer uma dessas partes pode
implicar em problemas no projeto de classes. O desenvolvedor, atento, percebe e
melhora seu projeto de classes de acordo.
Ao longo do livro, descreveremos padrões que podem ajudar o praticante a per-
ceber problemas de design específicos, como baixa coesão, alto acoplamento e com-
plexidade desnecessária.
59
Capítulo 6
Qualidade no Código do Teste
No capítulo anterior, discutimos que os testes podem eventualmente indicar proble-
mas no código do teste. Com essa informação em mãos, desenvolvedores podem
refatorar o código e melhorá-lo. Mas para que isso aconteça, o código do teste deve
ser o mais claro e limpo possível.
Escrever testes deve ser algo fácil e produtivo. Todas as boas práticas que o desen-
volvedor aplica no código de produção pode ser utilizado no código do teste também,
para que ele fique mais claro e mais reutilizável.
Nas seções a seguir, discutiremos práticas que tornam os testes mais fáceis de
ler e manter.
6.1. Repetição de código entre testes
Casa do Código
A equipe que odiava os testes
Uma vez conversando com um aluno, ele me comentou que a equipe
escrevia testes e que o projeto que atuavam possuía uma bateria de testes
imensa, mas pasmem: eles odiavam os testes!
Curioso pelo assunto, comecei a fazer perguntas para entender melhor
qual era o real problema deles. Após alguns minutos de conversa, desco-
bri que o que os incomodava era o fato de que qualquer alteração sim-
ples no código de produção impactava em profundas alterações no có-
digo dos testes. Ou seja, eles gastavam 30 segundos implementando uma
nova funcionalidade, e 30 minutos alterando testes.
Por que isso aconteceu? A resposta é simples: falta de cuidado com o
código dos testes. Agora nossos testes são automatizados, eles são código.
E código ruim impacta profundamente na produtividade da equipe.
Todo o carinho que os desenvolvedores tem com seus códigos de produ-
ção deve acontecer também com o código de testes. Evitar repetição de
código, isolar responsabilidades em classes específicas e etc, são funda-
mentais para que sua bateria de testes viva para sempre.