Fala rapaziada, tudo certo?
Já faz mais de dez anos que o Desenvolvimento Guiado por Teste (TDD) chegou na indústria, eu achando que isso era novidade. Ele veio como parte da onda do Extreme Programming (Programação Extrema – XP). Assim, desde então, foi adotado pelo Scrum e virtualmente por quase todos os outros métodos da Agile. Até mesmo equipes que não são da Agile usam TDD.
Quando escutei falar pela primeira vez de “Test-first programming” fiquei com a pulga atrás da orelha, aliás quem não ficaria? Escrever seus testes de unidades antes? Quem faria isso né não? Mas sabia que não é tudo que se pode dispensar de primeira.
Desde então, aprendi que TDD é muito mais que um simples truque para abreviar o ciclo de tempo. A disciplina tem todo um repertório de benefícios que descreverei nos próximos parágrafos.
Mas primeiro preciso dizer o seguinte:
- TDD funciona e vou te provar;
Há muitos blogs e artigos controvérsos falando sobre TDD, escritos ao longo dos anos. No começo, eles eram tentativas sérias de criticar e entender. Atualmente, não passam de bullshit. O ponto fundamental é que TDD funciona e todo mundo precisa superar isso.
Sei que isso soa estridente e unilateral, mas dados os números, não acho que cirurgiões tenham que defender que a higienização das mãos é super importante, assim como programadores não precisam defender o TDD.
Como você pode se considerar um profissional se não souber que todos os seus códigos funcionam? Como pode saber se todos eles funcionam se não testá-los a cada mudança que efetuar? Como pode testá-los a cada mudança efetuada se não tiver testes de unidades automatizados que forneçam uma alta cobertura? Como pode obter essas unidades sem TDD?
A ultima sentença exige uma elaboração. O que, afinal, TDD?
As Três Leis do TDD
- Você não pode escrever nenhum código de produção até que tenha escrito antes um teste de unidade que detecte uma falha;
- Você não pode escrever mais de um teste de unidade do que o suficiente para a falha – e não compilar é não ter feito;
- Você não pode escrever mais códigos de produção que seja suficientes para passar pelo atual teste de unidade;
Essas três leis o colocam em um ciclo que talvez tenha trinta segundos de duração. Comece com uma pequena porção do teste de unidade. Mas em poucos segundos, você terá que mencionar o nome de alguma classe ou função que ainda não escreveu fazendo, portanto, com que o teste de unidade falhe ao compilar. Então, será preciso escrever o código de produção que fará com que o teste compile. Mas você não pode escrever mais do que isso, portanto comece a escrever mais códigos de teste de unidade.
E o ciclo continua. Adicione um pouco ao código de teste. Adicione um pouco ao código de produção. Os dois fluxos de código crescem simultaneamente e em componentes complementares. Os testes se encaixam no código de produção como um anticorpo em um antígeno.
Os benefício das cerimônias
Certeza
Se você adotar TDD como uma disciplina profissional, escreverá dezenas de testes diariamente, centenas por semana e milhares todos os anos. Manterá todos eles ao seu alcance e os usará sempre que fizer qualquer mudança em seu código.
Taxa de Injeção de Defeitos
Sempre devemos utilizar o bom senso se o seu software não é de missão crítica. Se há um bug, ninguém morre e ninguém perde milhões de dólares. Portanto, eu posso me dar ao luxo de fazer o envio com base em nada mais do que esses testes. Por outro lado, se o software tem milhares de usuários e apesar da adição de varias linhas de codigo, e tiver alguns bugs dos quais são de natureza cosmética. Então é possível saber que a taxa de injeção de defeitos é bem baixa.
Isso não é um efeito isolado. Há diversos relatos e estudos que descrevem uma redução significativa nos defeitos. Da IBM à Microsoft, uma empresa após a outra e equipe após equipe tem experimentado reduções nos defeitos em 2x, 5x ou em até 10x. Esses são os números que profissionais algum pode ignorar.
Coragem
Por que você não corrige o código ruim quando o vê ? Sua primeira reação ao ver uma função bagunça é “Isso está uma zona, precisa ser limpo“. Sua segunda reação é “Não vou colocar a mão nisso aqui!“. Por quê? Porque sabe que se tocar corre o risco de quebrar; e se quebrar, a responsabilidade passa a ser sua.
Mas e se você pudesse ter certeza de que a limpeza não danificaria nada? E se tivesse aquele tipo de certeza que acabei de mencionar? E se pudesse clicar em um botão e saber em 90 segundos que suas mudanças não quebraram coisa alguma e só promoveram benefícios?
Esse é um dos benefícios mais poderosos do TDD. Quando você tem um conjunto de teste, você perde todo o medo de efetuar mudanças. Ao ver um código ruim, você simplesmente o arruma. O código se torna argila que você pode esculpir em estruturas simples e agradáveis.
Quando programadores perdem o medo de fazer limpeza, eles fazem! Um código limpo é mais fácil de ser entendido, alterado e aumentado. Os defeitos tornam-se menos prováveis porque o codigo fica mais simples. A base melhora solidamente, em vez do apodrecimento normal ao qual nossa indústria tem se acostumado.
Que programador profissional pode permitir que esse apodrecimento continue?
Documentação
Você ja utilizou uma estrutura de trabalho terceirizada? Normalmente, o terceiro lhe envia um manual bem formatado feito por programadores de tecnologia. O manual típico emprega 27 fotos, oito por dez, colorida e brilhantes, com círculos, flechas e um parágrafo na parte de trás de cada uma explicando como configurar. implantar, manipular e utilizar uma estrutura de trabalho de forma geral. No final, no apêndice, há com frequência uma pequena seção que contém todos os exemplo de código.
Qual é o primeiro lugar que você checa no manual? Se você for um programador irá aos exemplos de código. Você faz isso por que sabe que o código irá lhe dizer-lhe a verdade. As 27 fotografias com todos os seus círculos e flechas, além do parágrafo explicativo atrás podem ser bonitas, mas se quiser saber como usar códigos, precisa conseguir lê-los.
Cada um dos testes de unidades que você escreve quando segue as três leis é um exemplo escrito de código, descrevendo como o sistema deve ser usado. Se você seguir as três leis, então haverá um teste de unidade que descreve como criar cada objeto no sistema, de todas as formas pelas quais esse objeto pode ser criado. Haverá também , um teste de unidade que descreverá como chamar cada função no sistema, de todas as maneiras pelas quais essas funções podem ser significativamente chamadas. Para qualquer coisa que você precisar saber como se faz, haverá um teste de unidade com a descrição em detalhes.
Os teste de unidades são documentos. Eles descrevem o nível de design mais baixo do sistema. Eles não têm ambiguidade, são precisos e escritos em uma linguagem formal que o público entende. São a melhor forma de documentação de nível mais baixo que existe. Que profissional não forneceria tal documentação?
Design
Quando você segue as três leis e escreve seus primeiros testes, encontra um dilema. Com frequência, sabe exatamente qual o código quer escrever, mas e essas três leis lhe dizem para escrever um teste de unidade que falha porque aquele código não existe! Isso significa que você precisa testar o código que está para escrever.
O problema em testar códigos é que você precisa isola-los. Costuma ser difícil testar uma função se aquela função chama outras funções. Para escrever esse teste, você precisa descobrir alguma forma de dissociar a função das demais. Em outras palavras, a necessidade para testar primeiro o força a pensar em um bom design.
Se você não escrever seus testes primeiro, não há força que o impeça de dissociar todas as funções em uma massa que não possa ser testada. Se escrever seu teste depois, pode ser capaz de testar os inputs e outputs da massa total, mas provavelmente será difícil testar as funções individuais.
Portanto, seguir as três leis e escrever seus testes primeiro, gera uma força que o impele a um design mais bem dissociado. Que profissional não empregaria ferramentas que levam um design melhor?
“Mas eu posso escrever ✍ meus testes depois”, você diz. Não, não pode. Não, de fato. Você pode escrever alguns testes depois. Pode até mesmo abordar a alta cobertura posteriormente se for cuidadoso o suficiente para mensurá-la. Mas os testes que escrever após o fato são defensivos. Os que escrever antes são ofensivos. Testes feitos após o fato são escritos por alguém que já está investindo no código e sabe como o problema foi resolvido. Não há como esses testes serem incisivos quanto os que são escritos primeiro.
A Opção Profissional
A conclusão disso tudo é que TDD é uma opção profissional. É uma disciplina que potencializa a certeza, a coragem, a redução de falhas, a documentação e o design. Com tudo isso em jogo, sua não utilização pode ser considerada falta de profissionalismo.
O que o TDD Não É
Apesar de todos os seus pontos positivos, TDD não é uma religião ou fórmula mágica. Seguir as três leis não garante qualquer um desses benefícios. Você ainda pode escrever códigos ruins mesmo fazendo os testes primeiro. Na verdade, você pode escrever testes ruins.
De modo similar, há situações em que seguir as três leis é simplesmente impraticável ou inapropriado. São situações raras, mas existem. Nenhum desenvolvedor profissional deve seguir uma disciplina quando ela faz mais mal que bem.
Bibliografia
MARTIN, Robert. O codificador limpo: Um Código de Conduta para Programadores Profissionais. [S. l.: s. n.], 2012.
