Desenvolvimento de Plug-ins Orientado a TestesMá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

• Vantagens – 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– Obriga o desenvolvedor a pensar na implementação final

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

Figura 2. O PDE JUnit executa os testes uma nova instância do Eclipse criada em tempo de execução.

•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.

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

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

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

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