Desde o início do desenvolvimento de software até os dias atuais é notável a grande mudança na forma como aplicações são desenvolvidas. Com o crescimento dos sistemas e a complexidade dos requisitos aumentando, foi ficando cada vez mais complicado identificar e corrigir falhas de código (ou até mesmo falhas nos requisitos) rapidamente, sem perdas para cliente e empresa.
Metodologias foram criadas justamente para tentar diminuir esta quantidade de erros que existiam. Foram adotadas metodologias em cascata, espiral e metodologias ágeis, dentre outras, todas com suas qualidades e defeitos, com o único objetivo de deixar o desenvolvimento mais confiável, mais correto. Uma das técnicas utilizadas nas metodologias ágeis é o Test Driven Development (TDD).
O TDD diz que se deve mudar a forma de programar. Ao invés de escrever o código e depois testar, no TDD deve-se testar antes de escrever.
O benefício do TDD foi comprovado em diversos estudos. Não só as aplicações possuíam menos defeitos, como o design do código era melhor do que as aplicações que não o utilizavam. TDD não é uma técnica exclusiva das metodologias ágeis de desenvolvimento. Trata-se de um método de desenvolvimento singular que pode ser utilizado tanto em metodologias ágeis como em metodologias que utilizam ciclos de vida em cascata ou espiral, só que ao invés de se aplicar em estórias, serão aplicados no desenvolvimento dos requisitos mapeados.
Motivação
Normalmente, durante o ciclo de desenvolvimento tradicional, os profissionais tendem a especificar uma funcionalidade e implementá-la para que depois, lá no fim, esta funcionalidade seja testada (isso quando são testadas).
Essa forma de desenvolvimento já se mostrou bastante ineficiente. O número de falhas no software é altíssimo. O tempo depurando a aplicação é muito superior ao de desenvolvimento em si, e com essa perda de tempo, junto com as próprias falhas de software, acaba se perdendo muito dinheiro. O que ainda se tornou pior é que software virou sinônimo de bug. Uma aplicação possuir erros se tornou uma coisa normal.
Agora, imagine se a construção de carros fosse parecida com o desenvolvimento de software. Ou mesmo um procedimento cirúrgico fosse feito da mesma maneira como é desenvolvido um software.
Foi nesse ponto que, através de estudos e acompanhamentos de outros processos, foi proposto o TDD como forma de minimizar as tantas falhas de software e aumentar a qualidade do código-fonte produzido.
Mas o que de fato vem a ser esse tal de TDD?
A filosofia do TDD é simples: código limpo e que funciona. Mas como chegar a este ponto?
O desenvolvimento orientado a testes segue um mantra no qual a premissa básica é: teste antes de implementar. Com esta simples inversão de etapas durante o desenvolvimento já se consegue grandes vantagens, tais como:
● Trazer o teste para mais perto do desenvolvedor (onde as regras de negócio estão sendo criadas ou implementadas);
● Documentar o código através de testes durante o desenvolvimento;
● Testes para funcionalidades desenvolvidas;
● Melhoria na qualidade do código. Código fácil de testar é código bem feito.
Mantra: Vermelho/Verde/Refatore
O mantra vermelho/verde/refatore é a base para se utilizar o TDD. Ele descreve o ciclo de tarefas que devem ser feitas ao implementar uma funcionalidade. Para iniciar o desenvolvimento com TDD, antes mesmo de escrever qualquer linha de código, primeiro será escrito um código que teste a funcionalidade.
Com o teste escrito, o mesmo é executado e falha, uma vez que a funcionalidade ainda não foi construída. Este passo parece não ser necessário (claro que o teste irá falhar, não se tem código ainda), porém é bastante importante e será abordado mais a frente.
Assim que o teste falhou, deve-se para fazer as modificações necessárias para ver o teste passar. Lembrando sempre, falha é progresso.
Depois de escrever o código para fazer o teste passar, deve-se executar o teste e verificar se está passando.
Um ponto importante neste momento (codificação) é nunca perder o foco do teste. Só se deve implementar a solução mais simples que faça o teste passar - este pequeno passo é conhecido como baby step.
Com o teste
...
Exibição do post interrompida. Para ler conteúdo completo, clique aqui
|