Esse não é apenas mais um artigo para falar o que é TDD. Muitos sabem – ou deveriam saber – que Test-Driven Development (TDD) é uma prática que se tornou muito popular na indústria de software nos últimos anos. A prática do TDD, resumidamente, se dá por escritas de testes antes mesmo de ter um código efetivamente pronto para ir para produção.

A prática teve muita aderência devido ao fato do desenvolvedor garantir que o seu software (ou boa parte dele) esteja em funcionamento e que futuras implementações nesse mesmo código, nas regras de negócios que mudam frequentemente, não alterem o resultado final do que será ou foi feito.

Aviso

Esse artigo tem por objetivo discutir TDD por uma outra ótica, por uma ótica além de código e mais abrangente ao negócio que você atua, as dificuldades que você enfrenta na prática e nas abordagens com o seu cliente/empresa. A discussão sobre os temas abordados é totalmente válida e enriquecedora com uma pitada de provocação.

As primeiras implicações na adoção do TDD

Essa prática se mostrou muito boa no mercado, e como tudo tem vantagens e desvantagens, saber como e quando usá-la não é uma receita de bolo, e sim um conjunto de experiências adquiridas ao longo do tempo e utilização da mesma.

Vamos aos fatos comumente citados:

• Testar software (ou o próprio trecho de código escrito) nem sempre é considerado dentro do tempo de desenvolvimento do próprio desenvolvedor. Pode parecer absurdo, mas alguns simplesmente passam essa responsabilidade para o time de Teste/QA. Afinal, não é para isso que eles existem? Não, não é. A responsabilidade do que você escreve é totalmente sua, desenvolvedor(a). A equipe de Teste/QA certamente precisa garantir que não haja bugs e/ou desacordos funcionais na sua entrega, mas ficar procurando bug de código mal escrito não é o trabalho deles! A equipe de Teste/QA trabalha para elevar a qualidade do sistema, e procurar bugs (muitas vezes simples) não é exatamente a melhor forma disso acontecer; nada será elevado.
• Escrever teste gasta tempo. Sim, gasta tempo e isso é um ponto a ser considerado na utilização da prática. Por um lado, você tem uma cobertura de testes a seu favor, do outro você tem um tempo limitado e precisa escrever/corrigir uma funcionalidade. Por onde ir então? Isso realmente depende da criticidade do que você precisa fazer para o negócio. Uma boa alternativa é tentar negociar o tempo da sua entrega e garantir que realmente não haja problemas, independente de você ter que escrever o teste ou uma outra manobra que garanta a qualidade.
• “Não consigo visualizar benefícios no TDD”. Essa é uma frase que pode ser ouvida de vez em quando, dita principalmente por quem nunca experimentou escrever testes. Além de prazo e custo, a qualidade talvez seja a ponta do triângulo dos projetos que seja menos visitada quando o projeto está apertado ou sob pressão. Então, por que não pensarmos em qualidade primeiro, escrevendo testes que façam sentido ao negócio e garantindo que o prazo e custo também se adequem a essa realidade? Vale a pena tentar!
• Não consigo usar TDD todo o tempo. Tudo bem! Isso não é problema. Como dito anteriormente, a prática do TDD tem se mostrado uma consequência de experiência de uso. Talvez você não tenha todos os requisitos no começo de um projeto, talvez você não esteja em um projeto tão grande que justifique a prática. Talvez você não tenha orçamento para isso. Talvez o TDD não seja um benefício nesse projeto.
• Com TDD eu serei menos produtivo. A prática realmente muda um pouco a ótica de produtividade. Primeiro, o que você considera produtividade? Escrever muitas linhas de código? Entregar rápido uma tarefa? Produtividade com escritas de testes primeiro se a resume a entregar um código menos complexo, com linhas de código escritas com qualidade, testáveis e passíveis de não retornarem chamados para você mesmo refazer o que deveria ter feito certo na primeira vez.

Agora, vamos aos benefícios que comumente não são vistos:

• O que ganhar efetivamente na prática do TDD? A primeira palavra que vem na cabeça é qualidade. Inevitavelmente você está seguro de que um trecho de código vai efetivamente fazer o que deveria ser feito quando o negócio solicitou aquilo. Um código correto e sem bug nos tira da zona de retrabalho. Retrabalho custa, faça certo da primeira vez.
• Redução da complexidade do seu código. Se o seu teste está difícil de ser escrito, provavelmente ele está complexo. A prática de escrever testes primeiro te leva a seguir o “Baby-Steps” (passos de bebê), onde você vai segregando os problemas em partes menores e reduzindo a complexidade do mesmo. Agora eu te pergunto: Quantos códigos você já pegou que pareciam mais um spaghetti do que uma regra de negócio do seu cliente? Quantos desses códigos foi possível refatorar?
• A linguagem do seu sistema tende a ficar orientada ao negócio que ele atende. A prática da escrita dos testes influencia na orientação de escrita do seu sistema. Em um mundo tão colaborativo como temos hoje, não faz sentido você escrever um código que só seja compreendido por você. Mesmo que você seja autônomo, pode ser que daqui uns meses volte em uma rotina e não sei lembre exatamente pra quê aquilo servia! Certamente com um código limpo você pode obter esse mesmo cenário, porém, você não garante que seu código limpo funcione exatamente como deveria.
• Identificando a necessidade de usar TDD no começo ou escrever testes depois. Existem cenários onde iniciar com TDD não seja possível, isso acontece. E de fato, a qualidade esperada não se resume apenas em falar de boca cheia que você implementa testes primeiro, mas sim que você tem uma estratégia de testes automatizados e para isso, a prática do TDD lhe auxilia! Quanto mais tempo você deixar os testes para serem feitos, mais custoso vai ficar a sua alteração. Na prática, fazendo os testes primeiro você obtém feedbacks mais rápidos sobre o que está fazendo, e assim, consegue mudar enquanto ainda é barato! Novamente, depende do cenário em que você se encontra.

TDD pode ser aplicado em diversas linguagens

A prática do TDD pode ser amplamente utilizada em diversas linguagens, tais como: C#, Java, Java Script, dentre outras. Dessa forma, a filosofia do que deve ser feito é aplicada e entendida independentemente da sua especialidade.

Conclusão

Nesse artigo fomentamos a utilização da prática do TDD, independente de linguagens ou frameworks. Ainda é realidade que projetos de software tendem a ter boa parte do seu orçamento gasto com retrabalho ou melhoria de funcionalidades que deveriam ter sido entregues corretamente da primeira vez. Essa prática demonstra um novo conceito e disciplina em desenvolver software, e mesmo não sendo adotada integralmente, deveria ser ao menos considerada em boa parte do projeto.