Desenvolvimento de Plug-ins Orientado a Testes Márcio Guedes, Edilson Mendes, Vamberto Lemos 01/out/2007

Introdução ao TDD TDD – Test Driven Development Defina os testes antes de implementar o software Comum para usuários de eXtreme Programming

Definição das iterações Adicionar um teste de forma rápida Executar os testes (mesmo que os testes falhem) Criar stubs para que os testes compilem Implementar a funcionalidade Executar os testes novamente Refatorar o código para remover duplicação de código Este processo se repete até que todos os testes sejam executados com sucesso

Vantagens e desvantagens Código simples Redução do tempo de detecção de defeitos Testes unitários correspondem diretamente ao código Obriga o desenvolvedor a pensar na implementação final Desvantagens Mudança no paradigma de desenvolvimento Difícil de ser usada em sistemas com entradas e saídas complexas

Arquitetura do Eclipse • Platform Runtime é o núcleo do Eclipse e sua função é iniciar o ambiente e carregar todos os outros plug-in e componentes. • Workspace é o componente que representa a área de trabalho no sistema de arquivos e que contem todos os projetos do usuário. • Workbench é a interface gráfica do Eclipse e contém todos os menus, barra de ferramentas, visualizadores e editores. • Team é o componente responsável por integrar o Eclipse com uma ferramenta de controle de versão. • Help é responsável por apresentar a documentação do Eclipse e de todos os plug-ins. Figura 1. Arquitetura de um plug-in do Eclipse.

PDE JUnit Evolução do Plug-in para JUnit Fornece a configuração JUnit Plug-in Test Uma nova instância do Eclipse é criada, carregando os projetos de plug-ins e de testes dos plug-ins a partir do wokspace. Em seguida, o JUnit Test Runner obtém o controle, executa os testes e quando a execução dos testes termina o Eclipse é fechado. Figura 2. O PDE JUnit executa os testes uma nova instância do Eclipse criada em tempo de execução.

Exemplo Baseado em um plug-in que adiciona uma View ao Eclipse Um view é um componente visual do Eclipse que provê informações sobre os recursos que o usuário está trabalhando no workbench, além disso, ele pode ou não estar relacionado a um editor

Figura 3. Implementação inicial do código de teste Exemplo – Passo 1 Criação do Plug-in de Teste Figura 3. Implementação inicial do código de teste

Exemplo – Passo 2 Implementação inicial do código da View para compilação do código de teste Figura 4. Implementação inicial do código da View para compilação do código de teste

Figura 5. Implementação do código da View para passar no teste Exemplo – Passo 3 Implementação do código da View para passar no teste Figura 5. Implementação do código da View para passar no teste

Figura 6. Resultado do teste Exemplo – Execução O Tester Plug-in deve ser executado usando a configuração JUnit Plug-in Test Figura 6. Resultado do teste

Referências McGregor, John D. and Sykes, David A. A pratical guide to testing object-oriented software. [S. l.]: Addison-Wesley, 2001. Beck, Kent. Test-Driven Development by example. [S. l.]: Addison-Wesley, 2002. Clayberg, E. and Rubel, D. Eclipse: Building Commercial-Quality Plug-ins. Addison-Wesley Professional, 2 edition, 2006. Gamma, E. and Back, K. Contributing to Eclipse: Principles, Patterns, and Plug-Ins. Addison-Wesley Professional, 2004. McAffer, J. and Lemieux, J. M. Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications. Addison-Wesley Professional, 2006. Guerra, Eduardo M. Um Estudo sobre Refatoração de Código de Teste. São Paulo: ITA, 2005, 191 p. Dissertação (Mestrado) – Divisão de Pós-Graduação do Instituto Tecnológico da Aeronáutica, Instituto Tecnológico da Aeronáutica, São José dos Campos, São Paulo, 2005. Tassey, Gregory. The Economic Impacts of Inadequate Infrastructure for Software Testing. [S. l.]: NIST, Planning Report, 2002. Dustin, Elfried. Effective software testing: 50 specific ways to improve your testing. [S. l.]: Addison-Wesley, 2003. http://en.wikipedia.org/wiki/Test_driven_development, acessado em setembro de 2007.

marcio.guedes@cesar.org.br edilson.mendes@cesar.org.br vamberto.lemos@cesar.org.br