segunda-feira, 18 de abril de 2011

.Net Compact Framework e TDD

Estou trabalhando no desenvolvimento de um aplicativo para um dispositivo móvel e resolvi utilizar TDD convencido de todas os benefícios que a abordagem traz para o desenvolvimento de aplicações.

Estou utilizando o Visual Studio 2008 que já traz o suporte necessário para criação de testes unitários, porém o ambiente me deixou um tanto decepcionado na aplicação da técnica, já que que tal metodologia exige que os testes possam ser executados rapidamente, porém após uma sorte descobri que os testes podem ser executados rapidamente (pule para o último parágrafo caso não queira ler a viagem).

Eu já havia criado meu projeto e implementado algumas coisas, sim eu sei que o TDD não recomenda isso, mas eu também não concordo com todas as práticas de TDD, ainda mais quando se está desenvolvendo código que não se sabe exatamente como será a estrutura, como é o meu caso. Após implementar algumas coisas e acreditar que a interface dos meus componentes não sofreriam mudanças significativas criei um projeto de testes.

Ao começar a pensar em como implementaria os testes me deparei com um problema: como iria simular os componentes que interagem com o hardware e seu retorno? A primeira coisa que me veio a cabeça foi mocks, porém para minha surpresa não existe nenhuma biblioteca que dê suporte a mocks no Compact Framework. Foi então que encontrei o artigo do Martin Fowler "Mocks Aren't Stubs". Problema resolvido. Criei stubs para os componentes que se comunicam com hardware e para as telas gráficas, pois a parte gráfica também é um pouco difícil de testar, já que se deve instanciar componentes gráficos que necessitam de interação com usuário. Como estou utilizando MVP para organizar as camadas da minha aplicação a visão é bastante simples e não faz muito sentido o esforço para testá-la como se fosse em um ambiente real, sendo assim, criei stubs para as telas também.

Após implementar alguns testes percebi que a execução era extremamente lenta, pois a IDE iniciava o emulador do móvel e executava os teste dentro deste ambiente. Em média este processo levava em torno de 5 minutos. Se considerarmos um cenário onde executamos 100 testes por dia, o que não é nenhum exagero, cada execução demorando 5 minutos, ficaríamos mais de 8 horas só executando testes.

Após esta experiência decepcionante abandonei a idéia de utilizar testes para mais tarde descobrir que se o projeto de testes for removido e depois adicionado novamente a solução, os testes não são executados no simulador, mas sim na própria máquina, o que é muito mais rápido e torna viável a aplicação de TDD. Não encontrei nenhuma explicação para este comportamento. Pretendo aplicar testes novamente aos meus projetos, mas infelizmente não será neste, pelo menos não por enquanto, pois os prazos se tornaram curtos para implementá-los agora :(