Criação de testes

Segundo a definição de refatoramento, as técnicas para implementá-lo devem ser descritas de forma a minimizar as chances de introdução de erros no sistema. Além disso, um dos pré-requisitos para a aplicação de tais técnicas é uma forma de garantir, com uma margem de confiabilidade, que o sistema continua funcionando como antes das mudanças. Esta forma

é a presença de uma boa bateria de testes que cubra, especialmente, os trechos de código afetados. Sendo assim, uma boa bateria de testes do sistema que será refatorado é um requisito para o projeto de refatoramento.

O servidor LightBase dispunha de poucos testes automáticos antes do início do projeto de refatoramento. A cada nova versão, o software passava por uma etapa de testes ad-hoc realizada por pessoas que não tinham experiência em tal função, uma forma ineficaz de verificar a presença de erros e problemas no sistema.

A estratégia de testes utilizada pela empresa revelou-se inadequada e pouco representativa, assim, o projeto de refatoramento não deveria confiar nesta estratégia visto que projetos deste tipo apresentam alto risco de inserir novos erros no sistema. Este foi outro obstáculo encontrado durante o planejamento do projeto de refatoramento. O planejamento também de uma estratégia de testes e de construção dos testes automáticos tornou-se necessário antes que o projeto pudesse prosseguir.

O primeiro objetivo com a criação dos testes é elaborar uma estratégia de testes para minimizar os riscos de introdução de problemas com as modificações feitas pelo refatoramento. Ou seja, certificar-se de que, após a execução do projeto e de acordo com os testes, o sistema continua funcionando como antes, já que não são previstas correções de erros. De acordo com o objetivo, testes de regressão são adequados às necessidades. Teste de regressão é o teste aplicado a novas versões para verificar se o sistema processa as mesmas funções da mesma maneira que as versões anteriores [Pfleeger, 1998].

A estratégia escolhida para testar o sistema foi utilizar testes funcionais e testes de sistema. Testes funcionais examinam a funcionalidade total do produto. Testes de sistema envolvem o exame de todo o sistema computacional. Os testes de unidade foram descartados, pois as mudanças propostas pelos refatoramentos, provavelmente, mudariam a estrutura de classes do sistema.

Os testes de sistema construídos para este projeto incluem testes de estresse e de performance numa tentativa de validar o desempenho e o comportamento do sistema em situações de atividade intensa.

A implementação e execução dos testes contaram com o apoio de uma terceira pessoa especialmente destinada a este fim. A Tabela 3.5 apresenta um sumário da estratégia de testes adotada para o projeto de refatoramento.

Objetivo Diminuir o risco de introdução de erros no sistema. Estratégia Teste de regressão.

Tipos de teste Testes funcionais e de sistema.

Tabela 3.5 - Sumário da estratégia de testes adotada.

Os testes funcionais têm o objetivo de validar o funcionamento do sistema através do exercício de suas funcionalidades. A construção dos testes funcionais para a validação do sistema foi realizada com o apoio de uma ferramenta de apoio a testes chamada VBUnit [VBUnit]. Esta ferramenta teve origem em outra ferramenta construída para testes de unidade de classes Java chamada JavaUnit [Gamma, 1999], [Beck, 1998]. Posteriormente o seu projeto foi reutilizado para a construção de ferramentas de testes para outras linguagens de programação.

O VBUnit facilita a construção de testes de unidade para componentes e/ou aplicativos desenvolvidos no Visual Basic. O LightBase dispõe de um componente de software chamado LbCom que funciona como cliente do servidor LightBase. O VBUnit foi utilizado juntamente com o LbCom para a construção dos testes funcionais automáticos para o sistema.

Uma ferramenta de testes desenvolvida em VisualBasic e também utilizando o componente LbCom foi construída para os testes de sistema. O objetivo principal desta ferramenta é estressar o servidor com atualização de informações nas bases de dados para verificar a consistência da informação após as atualizações concorrentes promovidas pela ferramenta.

Outra ferramenta também construída com o objetivo de apoiar a validação das modificações realizadas no servidor foi chamada de LogGraf. Esta ferramenta gera gráficos a partir do log de atividades do servidor LightBase. Através dos gráficos gerados por LogGraf é possível acompanhar a atividade de cada uma das linhas de execução ativas no servidor no momento da geração do log. Ssaber quais delas executavam, no momento de uma possível falha e quais métodos cada uma delas invocou durante sua execução, bem como, no momento da falha. Esta ferramenta facilita a análise da informação contida no log principalmente em casos de problemas gerados por acesso a informações compartilhadas entre linhas de execução que são difíceis de identificar.

O componente LbCom possibilita acesso à criação e modificação de bases e à manipulação das informações nelas contidas. Porém, o servidor LightBase tem uma lista de funcionalidades mais ampla e que não é coberta pelo componente como, por exemplo, a administração destas bases e a gerência de usuários. Para estes casos, testes de funcionalidade

especiais foram criados. A criação destes testes contou com o apoio da ferramenta CppUnit [CppUnit], que é a correspondente ao VBUnit e JavaUnit, para a linguagem C++. Estes testes utilizam diretamente a interface do servidor para a execução destes serviços.

Apesar da dificuldade envolvida na atribuição de um valor para a cobertura obtida pela bateria de testes criada, estima-se que este conjunto cubra menos de 50% do total das funcionalidades fornecidas pelo sistema. Uma cobertura mais ampla das funcionalidades do sistema inviabilizaria a execução do projeto devido às restrições de tempo.

A definição das funcionalidades a serem testadas foi baseada na interface do sistema que o componente LBCOM permitia acesso e na identificação das funcionalidades que estariam mais susceptíveis a mudanças dada a amplitude de sua complexidade dentro do sistema. Sendo assim, a análise de riscos foi a principal técnica utilizada para definir as funcionalidades que seriam contempladas na criação dos testes.