O que é TDD (Test-Driven Development)?

TDD (Test-driven development) não é novo, mas certamente está em voga. Originalmente inventado por Kent Beck como parte de sua metodologia de extreme programming, desde os anos 90 tem ganhado adeptos pelo mundo. No estudo open source languages 2016, quase metade de todos os entrevistados mencionou o TDD como sendo a metodologia de desenvolvimento que eles mais utilizam no dia a dia.
 

Em poucas palavras, o que é TDD?

A resposta mais simples e imediata para essa pergunta é: escreva os testes primeiro! Para cada novo recurso (user story):

• – Escreva testes para testar o recurso.
• – Execute testes (somente os novos testes podem falhar).
• – Escreva seu código para implementar o recurso.
• – Execute os testes (repita os passos 3 e 4 até passarem todos os testes).
• – Refatore o código (se necessário).

 
Claro, o diabo está nos detalhes e a simplicidade das etapas destacam o framework geral para cada recurso que precisa ser testado. Uma vez concluído o primeiro teste, a melhor prática é rever o código e os testes, em seguida refatorar para garantir um design limpo. O objetivo é obter código limpo e bem documentado e testes para que seja gerada uma solução completa e sustentável a longo prazo. Em seguida, o desenvolvedor pode passar então para o próximo bit de recurso do app.

Ao longo do tempo, seu aplicativo cria um conjunto abrangente de testes que oferece confiança no que foi construído até então. Subsequentemente, conforme as pessoas operam mudanças e os testes passam ou falham, você tem a confiança nas mudanças e compreende o que pode ter dado errado.
 

Por que o TDD é crucial para aplicativos empresariais

O TDD é particularmente importante para aplicações empresariais em grande escala, onde é muito fácil chegar a um patamar de monstruosidades sem a devida manutenção ao longo do tempo. Você pode facilmente perder o caminho se um aplicativo importante não for bem estruturado e testado consistentemente. Isso é extremamente importante para aplicativos corporativos porque estes precisam ser mantidos por um período muito longo de tempo. Portanto, ter uma boa suíte de testes que cubram a maioria dos recursos no seu aplicativo fornece a confiança necessária para seguir adiante quando mudanças são realizadas após anos de estrada.

Por exemplo, tomemos um pedaço de código que implementa uma regra de negócios e seus testes associados, e um user story para alterar a lógica da regra de negócios. Eu escrevo meus testes e os novos testes passam, mas um ou mais testes originais falham, este é um grande resultado. Agora muitas perguntas surgem – É um bug? É um efeito colateral? Talvez eu devesse ter reescrito o teste junto com a funcionalidade? Essas perguntas e alterações subsequentes são uma maneira conquistar a confiança no que o aplicativo deve produzir.
 

Você está coberto?

Se você é responsável por uma suite de software ou um aplicativo de software, você quer garantir que seus engenheiros irão adicionar os recursos e seus respectivos testes juntamente com eles. Esse é o ponto onde entra em cena a cobertura por ferramentas. Ao longo do tempo, diferentes desenvolvedores vêm e vão e possuir ferramentas de cobertura pode ajudar a prever tendências – se a sua visão estiver ultrapassada, você pode certificar-se de que há uma boa razão para isso.

Além disso, uma boa biblioteca de cobertura pode ajudar a determinar qual porcentagem do seu produto está coberta. O primeiro passo é determinar qual é a sua meta de cobertura. Você poderia pensar que deve sempre ser 100%… mas, até onde é factível? Pode ser interessante porque você imagina que cobriu tudo, mas o fato é que você provavelmente desperdiçou uma grande quantidade de tempo para testar coisas que não precisam ser testadas. Realisticamente, 100% não é o objetivo a ser alcançado.

Quanto do seu código deve ser coberto é algo que depende de muitos fatores. Se você tem um aplicativo que está operando em grande parte com lógica complicada, então você pode precisar de cobertura de código de 90%. Por outro lado, se o seu aplicativo é um framework pré-existente de objetos de negócios sem qualquer nova funcionalidade realmente complicada, você pode se satisfazer com 50% de cobertura do código. A quantidade de cobertura vai mudar dependendo do tipo de aplicativo e da funcionalidade envolvida, basicamente.
 

Python: O mestre do TDD

O Python se encaixa muito bem no contexto do TDD por conta dos pacotes e suporte disponível para testes. Neste caso, ter uma boa suite de testes quando se está construindo um grande sistema em Python torna esse grande sistema mais sustentável e confiável no que se refere à manutenção do sistema. Ele também pode reduzir o número de falhas devido a um nível mais elevado de testes. Em Python, seus tipos dinâmicos tornam crucial fazer testes de tipos, portanto, esteja sempre atento a esses casos.

Para que uma empresa obtenha valor de uma base de código a longo prazo, ela precisa ser facilmente alterada para fornecer rapidamente valor de novos negócios e é precisamente isso que o TDD ajuda a fazer. O Python contempla um bom conjunto de pacotes de teste, como pytest, nose e coverage, todos inclusos no ActivePython 2.7.13, 3.5.3 e 3.6.
 
Fonte: DZone.com
 
 

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.