manutenção de código de teste. boa razão para tratá-lo como qualquer outro código

quando falei sobre as vagas no nosso time de teste, mencionei que uma das vantagens de se trabalhar aqui na microsoft é que o time de testes é formado por engenheiros de software. a diferença é o objetivo do código.

se partirmos deste princípio, todos os cuidados, ou parte deles, que temos com o código do produto, deveríamos ter também com o código de teste. é muito comum eu conversar e acompanhar discussões onde parece que as pessoas esquecem que mesmo sendo um código de teste ele continua sendo essencialmente um código. logo, enfretaremos problemas se ele não for bem escrito. problemas como a manutenção. infelizmente devido a dificuldade na manutenção de código de testes ruins, faz com que, alguns usem isto como desculpa para dizer que é muito ruim ter muitos testes porque se gasta muito com manutenção.

a dificuldade na manutenção pode ser resultante de dois problemas: uso de ferramenta para gravação e geração de script de teste ou design e desenvolvimento ruim.

Alguns times utilizam ferramentas para gravar os passos a medida que navegam nas telas do sistema. esta ferramentas geram um script que depois será utilizado para fazer a mesma navegação e verificar se os resultados permanecem os mesmos. é fácil concluir como estes scripts se tornam frágeis. qualquer mudança na tela ou então na navegação faz com que estes testes estejam quebrados. além disto, normalmente estes scripts contém muito código que é utilizado para controle da ferramenta. Também muitas vezes estão mal organizados, mal estruturados e colocados todos num memos script ou método. Sem contar com a quantidade, na maioria das vezes excessiva, de código duplicado. Como consequencia, é muito difícil ler estes scripts e entender facilmente e rapidamente qual o seu objetivo. e na grande maioria das vezes, são de dificil manutenção.

já em 1997, num  evento para profissionais que trabalhavam com testes, The Los Altos Workshop on Software Testing (LAWST), este assunto foi discutido. Cem Kaner, documentou os resultados das discussões neste documento Improving the Maintainability of Automated Test Suites (https://www.kaner.com/pdfs/autosqa.pdf). é interessante notar o comentário dele:

"The most common way to create test cases is to use the capture feature of your automated test tool. This is absurd... The slightest change to the program’s user interface and the script is invalid. The maintenance costs associated with captured test cases are unacceptable." (o grifo é meu - fonte infoQ) 

não é a toa que muitos times mais maduros de testes optam por não utilizar tais ferramentas. passam então a desenvolver os seus próprios testes usando frameworks apropriados. mas isto não leva automaticamente a um código de teste de fácil manutenção. também é comum encontrarmos pessoas que acreditam que este código não precisa ter a mesma qualidade. logo, passam a ignorar as boas práticas de programação. não é incomum encontrar testes escritos como grandes "tripas" de código dentro de um mesmo método. misturando código que será utilizado pela infra-estrutura com código que representa efetivamente o teste. Duplicação massissa de código em diversas partes dos testes. estes códigos também são difíceis de manter e possuem um alto custo. apresentam a mesma dificuldade para se identificar o seu real objetivo.

a solução deste problema é básica (não quero dizer que é simples): reconhecer que desenvolvimento de testes automatizados é desenvolvimento de software. esta foi a conclusão e uma das sugestões dada por Dale Emery em seu paper publicado recentemente: Writing Maintainable Automated Acceptance Tests. Neste artigo ele mostra como eliminar dois problemas apontado por ele: detalhes incidentais e duplicação. Para resolvê-los ele usa refatoração.

se a premissa cima fora aceita, desenvolvimento de testes automatizados é desenvolvimento de software, boas práticas serão aplicadas. assim naturalmente o código se tornará mais legível e de fácil manutenção.

recomendo fortemente a leitura do artigo de Dale Emery. se preferir poderá ler a compilação e comentários feitos por Chris Sims no infoQ, excelente artigo.

[]s

       

Powered by Qumana