Clique aqui para ler esse artigo em PDF.
TestComplete
Testes automáticos de aplicações
Conforme suas aplicações vão se tornando maiores, um problema em potencial começa a aparecer: a introdução de novos bugs no programa quando são feitas alterações no código. Você tem o programa relativamente estável, quando é solicitada uma modificação qualquer. A mudança é implementada, mas começam a aparecer erros em locais que funcionavam anteriormente.
Esse é um pesadelo que atormenta qualquer desenvolvedor, a ponto de alguns evitarem fazer mudanças substanciais no código. Isso se torna pior quando avaliamos nosso código e verificamos que está uma verdadeira bagunça e necessitamos fazer uma faxina nele (em “desenvolvimentês”, poderíamos chamar isso de refactoring).
Como fazer essas mudanças sem criar um novo problema? A resposta está em testes automatizados. Cria-se uma rotina de testes, que são executados a cada nova mudança, para verificar se não foram introduzidos erros. Essa rotina poderia ser feita manualmente, a partir de uma lista – a cada mudança, todos os itens da lista são verificados e, caso não haja erros, passa-se para a fase seguinte. Com um programa grande, torna-se demorado executar todos os testes, além de ter o problema de pular alguns passos. Após algum tempo, os testes são relaxados ou deixam de serem executados e os problemas aparecem adiante.
Uma solução é usar um Unit Testing, que pode ser feito usando DUnit (para Delphi) ou NUnit (para .NET): cria-se testes automatizados para os métodos das classes, que são executados a cada mudança, verificando a introdução de erros. Isso já é um grande passo, pois à medida que temos testes confiáveis, estamos seguros que não introduzimos erros em nossos métodos, além de ter uma base de teste sempre confiável, que é executada sempre da mesma maneira.
Nota: veja uma introdução ao DUnit com Delphi na edição 52.
O Unit Testing tem algumas limitações:
·Como garantir que a interação entre os métodos não criou novos erros? Embora tenhamos testado os métodos individualmente, nem sempre podemos garantir que a interação entre as classes esteja correta. Por exemplo, a classe funciona bem com uma instância, mas como funciona com duas instâncias ativas?
·Como fazer testes visuais: se um método é essencialmente visual (uma rotina de desenho na tela, por exemplo), como garantir que o resultado está correto sem verificá-lo manualmente?
·Como testar a interface de usuário? Devemos simular cliques do mouse ou teclar algo para obter um resultado – como fazer isso?
·Como verificar se a aplicação se comporta bem ao longo do tempo? Como saber se, após uma hora de uso, a aplicação não travará ou apresentará erros?
Podem-se criar testes que passem por cima de algumas dessas limitações, porém isso nem sempre é fácil, muitas vezes o teste a ser criado passa a ser tão ou mais complexo que o próprio código a ser testado (nesse caso, será que é necessário um projeto para testar o projeto de testes?)." [...] continue lendo...
