IDENTIFICANDO E CORRIGINDO FALHAS DURANTE O DESENVOLVIMENTO DE SISTEMAS UTILIZANDO TDD

...

De acordo com Pressman (2010, p.59), “Jacobson [Jac02]‘Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo moderno de software. Tudo é ágil. [...]’”. Ela idealiza a rápida entrega do software operacional, dá menos importância para produtos de trabalho intermediários, adota os clientes como parte da equipe de desenvolvimento e trabalha para eliminar a atitude “nós e eles”, que tende a permanecer em muitos projetos de software.

Um dos fatores que faz um sistema ter ganho em agilidade é a qualidade dos testes que é aplicada. Em um sistema bem testado, não haverá retrabalho. Uma das maneiras de testar um sistema é utilizando TDD.

O Desenvolvimento Dirigido por Testes (TDD) tem por idealizador Kent Beck e uma das diferenças do TDD, em relação a outros métodos, é que com TDD o desenvolvedor vai evoluindo seu código aos poucos, conforme explora o problema, com o uso de testes automatizados escritos antes da solução sequer existir.

De acordo com Beck (2003), “[...] é uma abordagem evolutiva para o desenvolvimento que combina teste anterior de desenvolvimento, onde você escreve um teste antes de escrever código de produção apenas o suficiente para cumprir esse teste e a refatoração.”

Pode-se perder um pouco de um dos maiores benefícios de TDD, o feedback rápido sobre o que está sendo gerado. Nesse ponto, o design incremental é apresentado. A ideia é que a solução seja criada em pequenos passos, sendo eles: Escreva um teste que falhe; Faça o teste passer de maneira rápida e Refatore.

Um ponto importante em TDD é não ficar “preso” ao mesmo teste por muito tempo. Deve-se tentar resolvê-lo de forma rápida. Caso não consiga testá-lo rapidamente não se deve ficar preso a este teste, mas sim iniciar outro meio de “como fazer” o mesmo teste, para que o mesmo seja feito, testado e, se houver resultados positivos, refatorá-lo futuramente. Caso não haja melhoria, deve-se simplesmente voltar à versão anterior do projeto, que já passou por todas as etapas, foi refatorado e então voltou a ser testado, e continue a partir dele. Dessa forma, não há perda de tempo com depuração.

Vale acrescentar que tempo não é perdido com testes. Na verdade, quando o assunto a ser testado é conhecido pelo programador e os testes são bem desenvolvidos, muito tempo é pode ser poupado na etapa de programação.

3 METODOLOGIA

Para guiar a pesquisa foi “Fundamentos de Metodologia Científica” – LAKATOS & MARCONI (Atlas, 2003). Esse livrotrata do processo de produção de um trabalho de conclusão de curso, seus procedimentos sistemáticos e racionais, e de como estes contribuem na formação do conhecimento.

O modelo “Estudo de Caso” parece ser o que mais se encaixa para responder a demanda apontada, já que contempla uma descrição de um demanda dentro de uma empresa, ou seja, a criação de testes dentro dos parâmetros estabelecidos para podermos testar determinado software.

O core do estudo estará na criação de testes, propriamente dito. É com base nesses testes que sairão as diretrizes que nortearão o trabalho. Como o foco é TDD, serão feitos testes unitários, em sua maioria. Dito isso, a pesquisa mencionada toma um cunho qualitativo, já que os dados coletados serão descritivos e documentados.

Após efetuar o levantamento de quais testes deverão ser feitos e efetuar tais testes seguindo a etapa detalhada a seguir.

Escreva um pequeno teste que falhe e que talvez sequer compile inicialmente. Como o código nem foi gerado, o teste não poderá prever seus erros.

Faça o teste passar da maneira rápida, cometendo qualquer “pecado” durante este processo. O teste foi realizado, realmente funciona e passa pelas condições impostas. Mas é preciso lembrar que ele não está pronto para testar e encontrar o erro em um programa. Foi apenas projetado para passar por uma determinada condição que satisfaça o problema inicial. Se necessário, escreva apenas a parte do código necessário para que o teste passe.

Refatore: elimine toda duplicação criada para fazer os testes passarem. O código gerado inicialmente pode ser melhorado por meio da refatoração. Com a refatoração, o código será escrito de forma mais simples, com menos linhas de comandos e codificações que outrora estavam duplicados em todo programa.

É importante lembrar também que, como o teste inicial foi feito sem o código, deverá ser modificado para melhor atender ao funcionamento de um programa em geral. Por isso, deve-se ter em mente que, para projetar um teste de alto nível, o programador precisa ter conhecimento sobre o assunto e principalmente saber como testá-lo e testá-lo de forma efetiva, que dê resultados.

O desenvolvimento do sistema propriamente dito poderá ser feito de forma modular. Nesse momento, existe a junção de pesquisa bibliográfica e a pesquisa qualitativa. Aqui tem-se então uma pesquisa de natureza aplicada, tendo em vista que gerará conhecimentos para aplicação prática.

Para auxiliar nos testes, é possível fazer uma descrição de testes a serem feitos e documenta-los por meio de frameworks de testes como JUnit, entre outros.

4 REFERÊNCIAS BIBLIOGRÁFICAS

BECK, K. “eXtreme Programming Explained”, Addison Wesley, 2000.

BECK, K. “Test Driven Development: