Por volta de 2000-2003 começou há
cogitar-se a possibilidade de testar primeiro ou seja, uma mudança de
paradigmas pois o teste de software inicialmente visto como uma das últimas
etapas do desenvolvimento (se não a última) passou a aparecer em primeiro lugar
no desenvolvimento inclusive guiando o mesmo. Esse paradigma chamado de Test
Driven Developement ou em uma tradução livre Desenvolvimento Guiado por Testes
consiste em criar o teste unitário antes do software em si utilizando-o como
guia para o desenvolvimento e é uma abordagem evolutiva para desenvolvimento de
software. O processo consiste nas seguintes etapas Red, Green e Refactory:
1. Red: O teste unitário é criado e
executado, inicialmente falhando pois o código a ser testado ainda não existe.
2. Green: O desenvolvedor então cria o
mínimo de código para que este teste unitário passe.
3. Refactory: Após o teste passar o
código criado é refatorado para melhorar sua implementação e o ciclo inicia-se
novamente.
A ideia fundamental por
traz desta prática é fazer com que os requisitos sejam pensados antes de “como”
a funcionalidade será implementada. Programadores tendem a gastar muito tempo
pensando em como será feita uma implementação e deixam em segundo plano o
objetivo do programa. Ao escrever o teste antes do programa, o programador
necessariamente precisa ter entendido com clareza os requisitos, ou seja, sabe
aonde quer chegar antes de ir (tem um objetivo especifico). Isto traz
benefícios como a identificação e eliminação de erros de comunicação como falta
de entendimento dos requisitos mais cedo no projeto, permite uma entrega mais
rápida de uma funcionalidade já que para cada ciclo uma funcionalidade deve ter
sido implementada (foco claro para o desenvolvedor), evita refabricações do
código intermináveis e atrasos na entrega de funcionalidades, e da mais
segurança (autoconfiança) ao programador sobre aquilo que foi implementado e
entregue. Não existe código desnecessário e sem teste; aplicação de testes de
regressão. TDD possibilita um código fracamente acoplável e com características
fortemente orientadas a objetos.
Sendo uma abordagem evolutiva na
qual o desenvolvedor escreve o teste antes de escrever o código funcional para
satisfazer aquelas condições de teste, afirma-se que ela consiste de pequenas
iterações onde novos casos de testes são escritos contemplando uma nova
funcionalidade ou melhoria e, depois, o código necessário e suficiente para passar
esses teste é
implementado. Então, o
software é refatorado
para contemplar as mudanças de forma que os testes continuem
passando. Cada pequena iteração possui
um micro objetivo, que será uma funcionalidade ou melhoria que deverá ser
implementada. Este micro objetivo terá sido alcançado quando os testes criados
antes da implementação do código passarem. Essa forma de implementar reduz o
escopo do que o desenvolvedor deve focar, já que ele pensará apenas no micro
objetivo, ao invés de se preocupar com todo o software. Esta técnica também permite que o
desenvolvedor escreva os testes se preocupando apenas com o comportamento
desejado da nova funcionalidade, ignorando sua implementação e garante que os
testes cobrem todo o código.
Como
todas as funcionalidades e melhorias do código começam com um teste, o
desenvolvedor precisa conhecer os casos
de uso e estórias que contemplem todos os requisitos e exceções do
sistema. Essa técnica obriga o
desenvolvedor a focar no requisito para escrever bons testes. Cada teste
adicionado deve cobrir uma funcionalidade ou melhoria que ainda não foi
implementada, então esse teste deverá falhar na sua primeira execução. Isso garante que o teste não passará sem a
necessidade de alterar o código. Com a falha no teste, o desenvolvedor deve
implementar o código necessário e suficiente para passar no novo teste, sem se
preocupar com a elegância do código.
Após implementado a nova funcionalidade/melhoria, os testes devem ser
executados novamente e, se todos os testes passarem, o desenvolvedor tem a
garantia que o código cumpre todos os requisitos testados. Se algum não passar, o código referente ao
teste que falhou deverá ser corrigido. Antes de adicionar um novo teste no
software, o desevolvedor deve refatorar o código, para evitar duplicação.
Segundo Kent Beck [BECK,
2003] o ciclo desta prática pode ser descrito como: (1) Escrever um programa de
teste (2) Executar o teste e verificar se ele falhou (deveria falhar porque a
funcionalidade ainda não foi implementada, a ideia é checar o ambiente de
configuração), (3) Escrever somente o código necessário para que o teste passe,
(4) Executar o caso de teste novamente e verificar se o teste passou[1], (5)
Re-fabricar o código e iniciar tudo novamente. Esse modelo também conhecido
como UTDD (Unit Test-Driven Development) e foi posteriormente incorporado ao planejamento
do XP (eXtreme Programing).
Nenhum comentário:
Postar um comentário