Dissertação de Mestrado - UFPE · Muitos dos problemas encontrados no uso do mecanismo de...

“Uma Abordagem Leve para Testar o ComportamentoExcepcional”

Por

Rafael Brito Di BernardoDissertação de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, Novembro/2011

Universidade Federal de PernambucoCentro de InformáticaPós-graduação em Ciência da Computação

Rafael Brito Di Bernardo

“Uma Abordagem Leve para Testar o ComportamentoExcepcional”

Trabalho apresentado ao Programa de Pós-graduação emCiência da Computação do Centro de Informática da Uni-versidade Federal de Pernambuco como requisito parcialpara obtenção do grau de Mestre em Ciência da Computa-ção.

Orientador: Fernando CastorCo-Orientador: Sérgio Soares

RECIFE, Novembro/2011

Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571

Di Bernardo, Rafael Brito Uma abordagem leve para testar o comportamento excepcional / Rafael Brito Di Bernardo - Recife: O Autor, 2011. xiii, 166 p: il., fig., tab. Orientador: Fernando José Castor de Lima Filho. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2011. Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Teste de software. I. Lima Filho, Fernando José Castor de (orientador). II. Título. 005.1 CDD (23. ed.) MEI2012 – 019

Dedico esta dissertação a minha esposa Paula, minha filhaSarah, aos meus Pais e familiares que me deram todo o

apoio necessário. Agradeço a Deus por me permitiralcançar mais esta conquista na minha vida.

Agradecimentos

Gostaria de agradecer em primeiro lugar a Deus por me possibilitar esta experiência, meajudar a caminhar nesta etapa da minha vida e me fortalecer em todos os momentos.Sem Ele nada disso teria acontecido. Agradeço a minha esposa Paula e minha filha Sa-rah por me apoiarem nesta jornada incentivando sempre o meu crescimento. Agradeçotambém por compreenderem os momentos que não pude estar mais presente devido àdedicação a este trabalho. Agradeço aos meus pais, Pascoal e Loide, e toda a minhafamília por sempre incentivarem o meu crescimento acadêmico, profissional e pessoal.Sou agradecido por mais uma vez ter a oportunidade de ser orientando do professorFernando Castor sempre disponível, atencioso e cuidadoso para que o trabalho fosseconduzido da melhor maneira possível. Agradeço ao meu co-orientador Sérgio Soarespelo suporte necessário inclusive por ter me recebido no programa de mestrado antesmesmo do professor Fernando assumir nesta instituição de ensino. Também sou agrade-cido aos Professores Nélio Cacho, Roberta Coelho, Fernando Castor, Sérgio Soares e aoRicardo Sales por terem contribuído para as publicações relacionadas a este trabalho.

iv

Resumo

Muitos dos problemas encontrados no uso do mecanismo de tratamento de exceçõessão causados pela falta de projeto e teste do comportamento excepcional de um sistemaem fases iniciais do desenvolvimento de software. Como consequência, exceções sãopropagadas de forma inesperada durante causando impacto negativo na confiabilidadede um software.

Neste trabalho apresentamos uma abordagem que possibilita projetar testes desdeas atividades iniciais do desenvolvimento e verificar, em tempo de execução, como asexceções trafegam ao longo de um sistema. Através da especificação do fluxo excepci-onal esperado é possível determinar se uma exceção foi propagada corretamente. Umsegundo uso desta abordagem destina-se ao auxilio das atividades de manutenção de umsistema. Para isto, uma versão inicial existente é especificada e os testes são executa-dos nas novas versões ao longo da evolução do sistema. Com isso é possível verificara consistência do comportamento excepcional a cada nova versão. Um benefício daabordagem proposta deve-se ao fato de que os testes escritos servem como a própriadocumentação viva do sistema mantendo-a sempre atualizada.

Para a avaliação desta abordagem foram selecionados três sistemas: aTunes, jEdit eHealth Watcher. Através do seu uso foram descobertos dezesseis bugs. Deste total dozeforam erros inéditos não reportados na base de bugs destes projetos. Não somente bugsforam descobertos com a utilização desta abordagem. Do ponto de vista de testes auto-matizados, como artefatos de documentação, foram apontadas diversas diferenças entreas versões dos sistemas com relação aos fluxos excepcionais testados. Para auxiliar aautomação dos testes, a abordagem foi implementada como uma extensão do frameworkJUnit. Os testes especificados nesta extensão contém informações complementares so-bre o fluxo excepcional esperado.

Palavras-chave: Tratamento de exceções, teste, comportamento excepcional, especifi-cação do comportamento excepcional.

v

Abstract

Many of the problems found in the use of exception handling are caused by the lack oftesting and a priori design of the exceptional behavior. As a consequence, exceptionsflow in unforeseen ways during the execution of a software system, having a negativeimpact on reliability.

This work presents an approach that allows testing activities from the initial deve-lopment and check, at runtime, the exceptions travels over a system. By specifying theexpected path is possible to determine if an exceptional flow occurred as expected. Asecond use of this approach is intended to aid the maintenance activities of a system.For this, an initial version of system is specified and the tests are performed in all newversions during the system evolution. With this approach it is possible to check the con-sistency of the exceptional behaviour with each new version. One benefit of the proposedapproach due to the fact that the written tests serves as proper documentation keeping italways updated.

To evaluate this approach we selected three systems: aTunes, jEdit and Health Wat-cher. Through its use sixteen bugs were discovered. Twelve errors were not reported inbugs database of evaluated projects. Not only bugs were discovered using this approach.From the viewpoint of automated testing as documentation, several differences were no-ted between the version of system streams related to the exceptional tested. To assistthe testing automation, the approach was implemented as an extension of the JUnit fra-mework. The tests specified in this extension contains additional information about theexpected exceptional flow.

Keywords: Exception handling, testing, exceptional behaviour, specification of excep-tional behaviour.

vi

Sumário

Lista de Figuras xv

Lista de Tabelas xvi

Lista de acrônimos xvii

1 Introdução 1

2 Fundamentos 52.1 Tolerância a falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Falha, erro e defeito . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Classificação de falhas . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Tolerância a falhas . . . . . . . . . . . . . . . . . . . . . . . . 6

Detecção de erros . . . . . . . . . . . . . . . . . . . . . . . . . 7Confinamento de erros . . . . . . . . . . . . . . . . . . . . . . 7Recuperação de erros . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Tratamento de falhas . . . . . . . . . . . . . . . . . . . . . . . 82.2 Tratamento de Exceções . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Tratamento de Exceções em Java . . . . . . . . . . . . . . . . . . . . . 102.4 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Estratégia de teste . . . . . . . . . . . . . . . . . . . . . . . . 13Teste de Unidade . . . . . . . . . . . . . . . . . . . . . . . . . 13Teste de Componente . . . . . . . . . . . . . . . . . . . . . . . 13Teste de integração . . . . . . . . . . . . . . . . . . . . . . . . 13Teste de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.2 Teste estrutural . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.3 Teste Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Particionamemnto de equivalência . . . . . . . . . . . . . . . . 15Análise do Valor Limite . . . . . . . . . . . . . . . . . . . . . 15Grafo Causa-Efeito . . . . . . . . . . . . . . . . . . . . . . . . 16Error-Guessing . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6 Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.1 Etapas do TDD . . . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

Passo 1: Pensar . . . . . . . . . . . . . . . . . . . . . . . . . . 19Passo 2: Barra vermelha . . . . . . . . . . . . . . . . . . . . . 19Passo 3: Barra verde . . . . . . . . . . . . . . . . . . . . . . . 20Passo 4: Refatoração . . . . . . . . . . . . . . . . . . . . . . . 21Passo 5: Repetir . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7 Programação Orientada a Aspectos . . . . . . . . . . . . . . . . . . . . 212.7.1 Pontos de Junção . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.2 Aspectj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Sintaxe básica do Aspectj . . . . . . . . . . . . . . . . . . . . 23Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Abordagem Proposta 273.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Priorizando os fluxos excepcionais . . . . . . . . . . . . . . . . 303.2 Tipos de fluxos excepcionais . . . . . . . . . . . . . . . . . . . . . . . 323.3 Teste do comportamento Excepcional . . . . . . . . . . . . . . . . . . 34

3.3.1 Utilizando a abordagem em aplicações existentes . . . . . . . . 34Selecionando os fluxos excepcionais mais importantes . . . . . 35Criação dos casos de testes . . . . . . . . . . . . . . . . . . . . 35Execução dos testes . . . . . . . . . . . . . . . . . . . . . . . . 36Verificação dos resultados . . . . . . . . . . . . . . . . . . . . 36Verificação de inconsistência e correção dos erros . . . . . . . . 36Reaplicação dos testes . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2 Utilizando a abordagem em novos sistemas . . . . . . . . . . . 363.3.3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.4 Monitorando exceções . . . . . . . . . . . . . . . . . . . . . . 463.3.5 Forçando exceções . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4 Como montar o ambiente de testes . . . . . . . . . . . . . . . . . . . . 48

4 Avaliação 514.1 Avaliação do sistema aTunes . . . . . . . . . . . . . . . . . . . . . . . 534.2 Avaliação do sistema jEdit . . . . . . . . . . . . . . . . . . . . . . . . 554.3 Health Watcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

viii

5 Trabalhos Relacionados 655.1 Verificação Estática . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Abordagens baseadas no teste do comportamento excepcional . . . . . 665.3 Abordagem baseada no processo de desenvolvimento . . . . . . . . . . 67

6 Considerações Finais 696.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2 Publicações relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . 706.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Appendices 79

A Casos de teste 80A.1 Atunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.1.1 Atunes 1.5 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . 80A.1.2 Atunes 1.5 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . 81A.1.3 Atunes 1.5 TC03 . . . . . . . . . . . . . . . . . . . . . . . . . 81A.1.4 Atunes 1.5 TC04 . . . . . . . . . . . . . . . . . . . . . . . . . 82A.1.5 Atunes 1.5 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . 82A.1.6 Atunes 1.5 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . 83A.1.7 Atunes 1.5 TC07 . . . . . . . . . . . . . . . . . . . . . . . . . 83A.1.8 Atunes 1.5 TC08 . . . . . . . . . . . . . . . . . . . . . . . . . 84A.1.9 Atunes 1.5 TC09 . . . . . . . . . . . . . . . . . . . . . . . . . 84A.1.10 Atunes 1.5 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . 85A.1.11 Atunes 1.5 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . 85A.1.12 Atunes 1.5 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . 85A.1.13 Atunes 1.5 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . 86A.1.14 Atunes 1.6 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . 87A.1.15 Atunes 1.6 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . 87A.1.16 Atunes 1.6 TC03 . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.17 Atunes 1.6 TC04 . . . . . . . . . . . . . . . . . . . . . . . . . 88A.1.18 Atunes 1.6 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . 89A.1.19 Atunes 1.6 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . 89A.1.20 Atunes 1.6 TC07 . . . . . . . . . . . . . . . . . . . . . . . . . 90A.1.21 Atunes 1.6 TC08 . . . . . . . . . . . . . . . . . . . . . . . . . 90A.1.22 Atunes 1.6 TC09 . . . . . . . . . . . . . . . . . . . . . . . . . 91

ix

A.1.23 Atunes 1.6 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . 91A.1.24 Atunes 1.6 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . 92A.1.25 Atunes 1.6 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . 92A.1.26 Atunes 1.6 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . 93A.1.27 Atunes 1.9 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . 93A.1.28 Atunes 1.09 TC02 . . . . . . . . . . . . . . . . . . . . . . . . 94A.1.29 Atunes 1.09 TC03 . . . . . . . . . . . . . . . . . . . . . . . . 94A.1.30 Atunes 1.09 TC04 . . . . . . . . . . . . . . . . . . . . . . . . 94A.1.31 Atunes 1.09 TC07 . . . . . . . . . . . . . . . . . . . . . . . . 95A.1.32 Atunes 1.09 TC10 . . . . . . . . . . . . . . . . . . . . . . . . 95A.1.33 Atunes 1.09 TC11 . . . . . . . . . . . . . . . . . . . . . . . . 96A.1.34 Atunes 1.09 TC12 . . . . . . . . . . . . . . . . . . . . . . . . 96A.1.35 Atunes 1.09 TC13 . . . . . . . . . . . . . . . . . . . . . . . . 97A.1.36 Atunes 1.09 TC14 . . . . . . . . . . . . . . . . . . . . . . . . 98A.1.37 Atunes 1.09 TC15 . . . . . . . . . . . . . . . . . . . . . . . . 98A.1.38 Atunes 1.09 TC16 . . . . . . . . . . . . . . . . . . . . . . . . 98A.1.39 Atunes 1.09 TC17 . . . . . . . . . . . . . . . . . . . . . . . . 99A.1.40 Atunes 1.10 TC11 . . . . . . . . . . . . . . . . . . . . . . . . 99A.1.41 Atunes 1.10 TC02 . . . . . . . . . . . . . . . . . . . . . . . . 100A.1.42 Atunes 1.10 TC03 . . . . . . . . . . . . . . . . . . . . . . . . 100A.1.43 Atunes 1.10 TC04 . . . . . . . . . . . . . . . . . . . . . . . . 101A.1.44 Atunes 1.10 TC07 . . . . . . . . . . . . . . . . . . . . . . . . 101A.1.45 Atunes 1.10 TC10 . . . . . . . . . . . . . . . . . . . . . . . . 102A.1.46 Atunes 1.1 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . 102A.1.47 Atunes 1.10 TC12 . . . . . . . . . . . . . . . . . . . . . . . . 103A.1.48 Atunes 1.10 TC13 . . . . . . . . . . . . . . . . . . . . . . . . 104A.1.49 Atunes 1.10 TC14 . . . . . . . . . . . . . . . . . . . . . . . . 104A.1.50 Atunes 1.10 TC15 . . . . . . . . . . . . . . . . . . . . . . . . 104A.1.51 Atunes 1.10 TC16 . . . . . . . . . . . . . . . . . . . . . . . . 105A.1.52 Atunes 1.10 TC17 . . . . . . . . . . . . . . . . . . . . . . . . 105A.1.53 Atunes 1.12 TC01 . . . . . . . . . . . . . . . . . . . . . . . . 106A.1.54 Atunes 1.12 TC02 . . . . . . . . . . . . . . . . . . . . . . . . 106A.1.55 Atunes 1.12 TC03 . . . . . . . . . . . . . . . . . . . . . . . . 107A.1.56 Atunes 1.12 TC04 . . . . . . . . . . . . . . . . . . . . . . . . 108A.1.57 Atunes 1.12 TC07 . . . . . . . . . . . . . . . . . . . . . . . . 108

x

A.1.58 Atunes 1.12 TC10 . . . . . . . . . . . . . . . . . . . . . . . . 109A.1.59 Atunes 1.12 TC12 . . . . . . . . . . . . . . . . . . . . . . . . 109A.1.60 Atunes 1.12 TC12 . . . . . . . . . . . . . . . . . . . . . . . . 110A.1.61 Atunes 1.12 TC16 . . . . . . . . . . . . . . . . . . . . . . . . 110A.1.62 Atunes 1.12 TC17 . . . . . . . . . . . . . . . . . . . . . . . . 111A.1.63 Atunes 1.13 TC01 . . . . . . . . . . . . . . . . . . . . . . . . 111A.1.64 Atunes 1.13 TC02 . . . . . . . . . . . . . . . . . . . . . . . . 112A.1.65 Atunes 1.13 TC03 . . . . . . . . . . . . . . . . . . . . . . . . 112A.1.66 Atunes 1.13 TC04 . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.67 Atunes 1.13 TC07 . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.68 Atunes 1.13 TC10 . . . . . . . . . . . . . . . . . . . . . . . . 114A.1.69 Atunes 1.13 TC11 . . . . . . . . . . . . . . . . . . . . . . . . 114A.1.70 Atunes 1.13 TC12 . . . . . . . . . . . . . . . . . . . . . . . . 115A.1.71 Atunes 1.13 TC14 . . . . . . . . . . . . . . . . . . . . . . . . 115A.1.72 Atunes 1.13 TC16 . . . . . . . . . . . . . . . . . . . . . . . . 116A.1.73 Atunes 1.13 TC17 . . . . . . . . . . . . . . . . . . . . . . . . 116

A.2 jEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2.1 jEdit 4.0 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2.2 jEdit 4.0 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2.3 jEdit 4.0 TC03 . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.2.4 jEdit 4.0 TC04 . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.2.5 jEdit 4.0 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2.6 jEdit 4.0 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2.7 jEdit 4.0 TC07 . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.8 jEdit 4.0 TC08 . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.2.9 jEdit 4.0 TC09 . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2.10 jEdit 4.0 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2.11 jEdit 4.0 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 121A.2.12 jEdit 4.0 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . . 122A.2.13 jEdit 4.0 TC13 . . . . . . . . . . . . . . . . . . . . . . . . . . 122A.2.14 jEdit 4.0 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . . 123A.2.15 jEdit 4.0 TC15 . . . . . . . . . . . . . . . . . . . . . . . . . . 123A.2.16 jEdit 4.1 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 123A.2.17 jEdit 4.1 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . . 124A.2.18 jEdit 4.1 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 124

xi

A.2.19 jEdit 4.1 TC03 . . . . . . . . . . . . . . . . . . . . . . . . . . 125A.2.20 jEdit 4.1 TC04 . . . . . . . . . . . . . . . . . . . . . . . . . . 125A.2.21 jEdit 4.1 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . . 126A.2.22 jEdit 4.1 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . . 126A.2.23 jEdit 4.1 TC07 . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.2.24 jEdit 4.1 TC08 . . . . . . . . . . . . . . . . . . . . . . . . . . 128A.2.25 jEdit 4.1 TC09 . . . . . . . . . . . . . . . . . . . . . . . . . . 128A.2.26 jEdit 4.1 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . . 128A.2.27 jEdit 4.1 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . . 129A.2.28 jEdit 4.1 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . . 129A.2.29 jEdit 4.1 TC13 . . . . . . . . . . . . . . . . . . . . . . . . . . 130A.2.30 jEdit 4.1 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . . 130A.2.31 jEdit 4.1 TC15 . . . . . . . . . . . . . . . . . . . . . . . . . . 130A.2.32 jEdit 4.2 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.2.33 jEdit 4.2 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.2.34 jEdit 4.2 TC03 . . . . . . . . . . . . . . . . . . . . . . . . . . 132A.2.35 jEdit 4.2 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . . 132A.2.36 jEdit 4.2 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . . 133A.2.37 jEdit 4.2 TC09 . . . . . . . . . . . . . . . . . . . . . . . . . . 133A.2.38 jEdit 4.2 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . . 133A.2.39 jEdit 4.2 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . . 134A.2.40 jEdit 4.2 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . . 134A.2.41 jEdit 4.2 TC13 . . . . . . . . . . . . . . . . . . . . . . . . . . 135A.2.42 jEdit 4.2 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . . 135A.2.43 jEdit 4.2 TC15 . . . . . . . . . . . . . . . . . . . . . . . . . . 135A.2.44 jEdit 4.3 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . . 136A.2.45 jEdit 4.3 TC02 . . . . . . . . . . . . . . . . . . . . . . . . . . 136A.2.46 jEdit 4.3 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . . 137A.2.47 jEdit 4.3 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . . 137A.2.48 jEdit 4.3 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . . 137A.2.49 jEdit 4.3 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.50 jEdit 4.3 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.2.51 jEdit 4.3 TC13 . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2.52 jEdit 4.3 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.2.53 jEdit 4.3 TC15 . . . . . . . . . . . . . . . . . . . . . . . . . . 139

xii

A.2.54 jEdit 4.3.2 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . 140A.2.55 jEdit 4.3.2 TC01 . . . . . . . . . . . . . . . . . . . . . . . . . 140A.2.56 jEdit 4.3.2 TC05 . . . . . . . . . . . . . . . . . . . . . . . . . 141A.2.57 jEdit 4.3.2 TC06 . . . . . . . . . . . . . . . . . . . . . . . . . 141A.2.58 jEdit 4.3.2 TC08 . . . . . . . . . . . . . . . . . . . . . . . . . 142A.2.59 jEdit 4.3.2 TC10 . . . . . . . . . . . . . . . . . . . . . . . . . 142A.2.60 jEdit 4.3.2 TC11 . . . . . . . . . . . . . . . . . . . . . . . . . 142A.2.61 jEdit 4.3.2 TC12 . . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.62 jEdit 4.3.2 TC13 . . . . . . . . . . . . . . . . . . . . . . . . . 143A.2.63 jEdit 4.3.2 TC14 . . . . . . . . . . . . . . . . . . . . . . . . . 144A.2.64 jEdit 4.3.2 TC15 . . . . . . . . . . . . . . . . . . . . . . . . . 144

A.3 Health Watcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144A.3.1 Health Watcher 1-2 OO TC01 . . . . . . . . . . . . . . . . . . 144A.3.2 Health Watcher 1-2 OO TC02 . . . . . . . . . . . . . . . . . . 145A.3.3 Health Watcher 1-2 OO TC03 . . . . . . . . . . . . . . . . . . 145A.3.4 Health Watcher 1-2 OO TC04 . . . . . . . . . . . . . . . . . . 146A.3.5 Health Watcher 1-2 OO TC05 . . . . . . . . . . . . . . . . . . 146A.3.6 Health Watcher 1-2 OO TC06 . . . . . . . . . . . . . . . . . . 147A.3.7 Health Watcher 1-2 OO TC07 . . . . . . . . . . . . . . . . . . 147A.3.8 Health Watcher 1-2 OO TC08 . . . . . . . . . . . . . . . . . . 148A.3.9 Health Watcher 1-2 OO TC09 . . . . . . . . . . . . . . . . . . 148A.3.10 Health Watcher 1-2 OO TC10 . . . . . . . . . . . . . . . . . . 149A.3.11 Health Watcher 1-2 OO TC11 . . . . . . . . . . . . . . . . . . 149A.3.12 Health Watcher 1-2 OO TC12 . . . . . . . . . . . . . . . . . . 150A.3.13 Health Watcher 1-2 OO TC13 . . . . . . . . . . . . . . . . . . 151A.3.14 Health Watcher 1-2 OO TC14 . . . . . . . . . . . . . . . . . . 151A.3.15 Health Watcher 1-2 OO TC15 . . . . . . . . . . . . . . . . . . 152A.3.16 Health Watcher 1-2 OO TC16 . . . . . . . . . . . . . . . . . . 152A.3.17 Health Watcher 1-10 AO TC01 . . . . . . . . . . . . . . . . . . 155A.3.18 Health Watcher 1-10 AO TC02 . . . . . . . . . . . . . . . . . . 155A.3.19 Health Watcher 1-10 AO TC03 . . . . . . . . . . . . . . . . . . 156A.3.20 Health Watcher 1-10 AO TC04 . . . . . . . . . . . . . . . . . . 156A.3.21 Health Watcher 1-10 AO TC05 . . . . . . . . . . . . . . . . . . 157A.3.22 Health Watcher 1-10 AO TC06 . . . . . . . . . . . . . . . . . . 157A.3.23 Health Watcher 1-10 AO TC07 . . . . . . . . . . . . . . . . . . 158

xiii

A.3.24 Health Watcher 1-10 AO TC08 . . . . . . . . . . . . . . . . . . 159A.3.25 Health Watcher 1-10 AO TC09 . . . . . . . . . . . . . . . . . . 159A.3.26 Health Watcher 1-10 AO TC10 . . . . . . . . . . . . . . . . . . 159A.3.27 Health Watcher 1-10 AO TC11 . . . . . . . . . . . . . . . . . . 160A.3.28 Health Watcher 1-10 AO TC12 . . . . . . . . . . . . . . . . . . 160A.3.29 Health Watcher 1-10 AO TC13 . . . . . . . . . . . . . . . . . . 161A.3.30 Health Watcher 1-10 AO TC14 . . . . . . . . . . . . . . . . . . 162A.3.31 Health Watcher 1-10 AO TC15 . . . . . . . . . . . . . . . . . . 162A.3.32 Health Watcher 1-10 AO TC16 . . . . . . . . . . . . . . . . . . 163

xiv

Lista de Figuras

2.1 Recuperação por avanço e retrocesso [74]. . . . . . . . . . . . . . . . . 72.2 Mecanismo de Tratamento de Exceções . . . . . . . . . . . . . . . . . 102.3 Hierarquia de exceções em Java . . . . . . . . . . . . . . . . . . . . . . 112.4 Join points de um fluxo de execução [28] . . . . . . . . . . . . . . . . . 232.5 Exemplo de advice em AspectJ . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Arquitetura em camadas de um sistema de informação . . . . . . . . . 283.2 Fluxos candidatos à criação de casos de teste . . . . . . . . . . . . . . 333.3 Tipos de fluxos excepcionais: Completo, Mínimo[58]. . . . . . . . . . 343.4 Visão da abordagem proposta para sistemas existentes[58]. . . . . . . . 353.5 Representação da propagação de exceções na arquitetura. . . . . . . . . 373.6 Etapas da abordagem para novos sistemas. . . . . . . . . . . . . . . . . 383.7 Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . 393.8 Diagrama de sequência . . . . . . . . . . . . . . . . . . . . . . . . . . 393.9 Implementação do caso de teste . . . . . . . . . . . . . . . . . . . . . 403.10 Criação das classes básicas . . . . . . . . . . . . . . . . . . . . . . . . 413.11 Visão jUnite tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.12 Exemplo de caso de teste . . . . . . . . . . . . . . . . . . . . . . . . . 443.13 Resultado de um caso de teste. . . . . . . . . . . . . . . . . . . . . . . 453.14 Transformação de tipo uma exceção. . . . . . . . . . . . . . . . . . . . 463.15 Criação de um projeto Aspectj. . . . . . . . . . . . . . . . . . . . . . . 493.16 Adicionando o JUnit ao projeto. . . . . . . . . . . . . . . . . . . . . . 503.17 Adicionando lib do JUnitE. . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1 Método savePictureToFile() . . . . . . . . . . . . . . . . . . . . . . . . 56

xv

Lista de Tabelas

2.1 Desiginadores de ponto de junção [45] pg.74 . . . . . . . . . . . . . . 24

4.1 Métricas do sistema aTunes. . . . . . . . . . . . . . . . . . . . . . . . 534.2 Resultado dos testes para as versões analisadas do aTunes. . . . . . . . 544.3 Falhas encontradas no sistema aTunes . . . . . . . . . . . . . . . . . . 544.4 Métricas do jEdit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.5 Resultado dos testes para as versões analisadas do jEdit. . . . . . . . . 574.6 Falhas encontradas no sistema jEdit. . . . . . . . . . . . . . . . . . . . 584.7 Métricas do Health Watcher. . . . . . . . . . . . . . . . . . . . . . . . 604.8 Resultado dos testes para as versões analisadas do HW. . . . . . . . . . 604.9 Detalhamento das falhas encontradas no HW. . . . . . . . . . . . . . . 61

xvi

Lista de acrônimos

GUI Graphical user interface

TDD Test Driven Development

LOC Lines of Code

XP eXtreme Programming

UFPE Universidade Federal de Pernambuco

I/O Input and output operation

AOP Aspect Oriented Programming

GUI Graphics User Interface

DAO Data Access Objects

xvii

1Introdução

Sistemas de software são geralmente compostos por um conjunto de componentes distri-buídos. Estes componentes lidam com entradas de diversas fontes e executam em umavariedade extensa de ambientes que exigem alta confiabilidade. Várias técnicas podemser utilizadas para atender essas exigências. Tratamento de exceções é uma dessas téc-nicas e está presente nas principais linguagens de programação [23]. Mecanismos detratamento de exceções ajudam os desenvolvedores a construírem aplicações robustas,separando o comportamento excepcional do fluxo de controle normal [44].

Mecanismos de tratamentos de exceções oferecem abstrações para: (i) representarsituações de erro dos módulos do sistema através de exceções; (ii) encapsular atividadesde tratamento de exceções em tratadores de exceções; (iii) definir partes dos módulosdo sistema como regiões protegidas para tratar ocorrências excepcionais; (iv) associaressas regiões protegidas aos tratadores, e (v) especificar explicitamente as interfacesexcepcionais dos módulos.

Se por um lado uma grande quantidade de código nos sistemas modernos é dedicadaà detecção e tratamento de erros [8, 19, 24], por outro lado, lidar com as manifestaçõesde erros / exceções em diferentes estágios de desenvolvimento ( por exemplo, elicitaçãode requisitos, projeto arquitetural e projeto de sistemas) tem recebido pouca atenção [26,32]. Os desenvolvedores tendem a dar atenção ao comportamento normal da aplicação,não se concentrando na concepção das atividades excepcionais (detecção e tratamentode erros)[30] . Eles costumam lidar com a detecção e tratamento das exceções apenasnas atividades de implementação [23]. Como consequência, mecanismos de tratamentode exceções não são utilizados de maneira adequada, comprometendo a confiabilidadedo sistema.

O código gerado para tratar exceções geralmente é propenso a erros [3] devido à faltade atenção com relação ao comportamento excepcional ao longo das fases de desenvol-

1

vimento de software. Este que inicialmente foi concebido para permitir a construção deum sistema mais robusto acaba por ser uma fonte de falhas [57].

Tendo em vista este problema, pesquisadores propuseram diferentes abordagens paraaliviar os problemas introduzidos pelo mau uso do mecanismos de exceções. Estas abor-dagens são normalmente baseadas em analise estática, testes e no processo do desenvol-vimento do software.

Abordagens baseadas em análise estática de código foram propostas com o objetivode revelar problemas relativos ao código de tratamento de exceções. Para dar suportea esta abordagem, ferramentas de análise estática são utilizadas para descobrir o fluxoexcepcional, do local onde a exceção é lançada ao local onde é capturada [9, 47, 55, 57].Esta técnica, no contexto de tratamento de exceções, possibilita o entendimento de comoum programa se comporta na presença de eventos excepcionais. No entanto, devido àslimitações inerentes a esta abordagem, combinado com as características das linguagensmodernas (como herança, polimorfismo e chamadas virtuais), tais abordagens costumamrelatar muitos falsos positivos ao sinalizar problemas relacionados ao fluxo indevidode exceções[69]. Assim, a verificação manual é geralmente requerida para verificarse o fluxo excepcional detectado pode de fato ocorrer. Também não são úteis quandoo sistema ainda está em desenvolvimento pois os fluxos excepcionais ainda não estãocompletos embora estes possam já estar especificados.

Muitas abordagens de desenvolvimento propõem ajudar na diminuição deste pro-blema [26, 32]. No entanto tais abordagem são fortemente baseadas em documentaçãoincorporando um overhead que pode ser um impeditivo ao seu uso. Experiências [14]têm mostrado que metodologias ágeis são usadas com sucesso no desenvolvimento deaplicativos modernos. Essas metodologias são baseadas em automação de testes e poucadocumentação. Também pode ser observado que os testes automatizados servem comoa própria documentação com relação à especificação do sistema. No entanto, estas nãolevam em consideração explicitamente o teste do comportamento excepcional.

Este trabalho tem por objetivo elaborar uma nova abordagem para especificação everificação do comportamento excepcional em um sistema de software. Em particular,estamos interessados em verificar se, os fluxos de propagação das exceções, a partir dospontos onde são lançadas até serem capturadas, estão corretos. Com o objetivo dar su-porte aos testes do comportamento excepcional definidos pela abordagem proposta, foiimplementada uma ferramenta como extensão do JUnit devido a este ser o frameworkmais utilizado para construção de testes de unidade automatizados. Em alguns cenárioseste framework foi utilizado [27, 56] de maneira mais ampla para dar suporte, por exem-

2

plo, a testes de integração. Espera-se que através do uso da abordagem seja possível de-tectar erros relacionados ao tratamento de exceções nos sistemas avaliados permitindoa criação de sistemas mais confiáveis. Devido a restrições de recursos para a elabora-ção de um experimento controlado, este estudo não tem o objetivo avaliar a abordagemproposta para sistemas novos. Este apenas limita-se a avaliar a abordagem no cenárioevolutivo para sistemas já existentes. Também não possui o objetivo de fornecer umanova abordagem de priorização de seleção dos fluxos excepcionais a serem testados,apenas concentra-se em demostrar os critérios utilizados para a criação dos casos de tes-tes para os sistemas avaliados. A perguntas que queremos responder neste trabalho é:A abordagem proposta permite a descobertas de bugs relacionados ao comportamentoexcepcional em um sistema de software?

Para a abordagem proposta, o teste do comportamento excepcional, o qual a partirdeste momento chamaremos de teste excepcional, é especificado de maneira similar aoJUnit, com pequenas adições referentes ao fluxo excepcional esperado. Um teste excep-cional pode ser utilizado para especificar possíveis fluxos excepcionais e compará-loscom os ocorridos em tempo de execução.

Esta abordagem pode ser usada: (i) em sistemas pré-existentes nas fases posterio-res ao desenvolvimento dando suporte às atividades de testes nas versões ao longo daevolução do sistema ou; (ii) antes do sistema ser implementado utilizando as premissasda metodologia TDD (Test Driven Development). Para avaliar a abordagem realizamostestes do comportamento excepcional de três sistemas. Dois deles são sistemas reais decódigo aberto e que possuem uma vasta base de usuários. São eles o jEdite1 e o aTu-nes2. O último sistema avaliado, Health Watcher3, é um sistema web implementado nalinguagem Java e AspectJ. Este foi desenvolvido no meio acadêmico e é utilizados comoreferência por diversos estudos científicos.

Através da avaliação dos três sistemas, foram descobertos dezesseis bugs, dos quaisdoze destes não haviam sido reportados anteriormente nos seus respectivos sistemas degerenciamento de bugs.

O resto desta dissertação está organizada da seguinte maneira. O capítulo 2 apresentaos fundamentos teóricos necessários para o entendimento do resto desta dissertação. Ca-pítulo 3 apresenta inicialmente um exemplo motivacional explicando porque o JUnitfalha na detecção de bugs causados pela propagação de exceções. Ainda neste capítuloapresentamos a abordagem proposta. No Capítulo 4 apresentamos os resultados obtidos

1jedit.org2www.atunes.org3http://www.comp.lancs.ac.uk/ greenwop/tao/implementation.htm

3

através da avaliação realizada. O Capítulo 5 apresentamos os trabalhos diretamente rela-cionados com a abordagem proposta. Por fim, no Capítulo 6 fazemos as consideraçõesfinais deste trabalho e apresentamos, resumidamente, suas principais contribuições.

4

2Fundamentos

Este capítulo tem por objetivo fornecer o embasamento teórico para o entendimento doresto desta dissertação. O primeiro ponto abordado são os conceitos sobre tolerância afalhas (Seção 2.1.3). O segundo tópico (Seção 2.3) aborda o funcionamento do meca-nismo de tratamento de exceções. Devido ao uso da linguagem Java para implementaros sistemas avaliados assim como a extensão da ferramenta de testes JUnit, o terceirotópico aborda tratamento de exceções no contexto da linguagem de programação Java.Na Seção 2.5 são abordados os fundamentos de teste de software. Devido à utilizaçãode TDD (Test Driven Development), a Seção 2.6 aborda os fundamentos e etapas destemétodo. Por fim, são abordados os conceitos de programação orientada a aspectos e umpouco da linguagem AspectJ. Estes conceitos são importantes para o entendimento domódulo de monitoramento das exceções utilizado neste trabalho.

2.1 Tolerância a falhasTolerância a falhas é a área de pesquisa dedicada a estudar o comportamento de sistemascomputacionais sujeitos à ocorrência de falhas [2]. Um sistema computacional consisteem um conjunto de componentes que interagem entre si [75] e com o ambiente do sis-tema. A característica dinâmica de um sistema de software é observada pela série deestados nos quais o sistema assume durante a sua execução, com a interação de seuscomponentes. Sob condições normais de processamento, o sistema irá avançar de um es-tado interno válido para o próximo por meio de uma transição válida. Em uma situaçãoadversa, essa transição ocasionará um erro.

5

2.1. TOLERÂNCIA A FALHAS

2.1.1 Falha, erro e defeito

Um defeito (failure) no sistema ocorre quando o serviço prestado pelo sistema desvia-se de seu objetivo especificado (desvio da especificação). Um erro é a parte do estadointerno do sistema que é suscetível a conduzir a um defeito subsequente, ou seja, oprocessamento posterior a partir deste estado pode levar a um defeito. Uma falha (fault)é a causa física ou algorítima do erro. A falha pode ocorrer dentro de um componentede hardware ou software.

2.1.2 Classificação de falhas

Podemos observar na literatura algumas classificações para falha [34, 75]. Laprie [34]as define como:

• Falhas Físicas: causadas por fenômenos adversos e podem ser internas ou exter-nas ao componente. Podemos citar como exemplo falhas geradas por componen-tes defeituosos, interferência eletromagnética, fadiga dos componentes físicos evariações ambientais.

• Falhas humanas: são imperfeições inseridas na implementação de um sistema quepodem ser de dois tipos: falhas de projeto (problemas de especificação e imple-mentação de sistemas) ou interação (violação de procedimentos de funcionamentoou manutenção).

Devido aos sistemas críticos serem construídos de modo a suportar falhas físicas, fa-lhas humanas são consideradas o problema mais sério quando pensamos em computaçãocrítica pois possuem um grande potencial de comprometer a confiabilidade e disponibi-lidade do sistema [33].

2.1.3 Tolerância a falhas

A confiabilidade é uma característica desejável para qualquer sistema de computaçãoe requisito obrigatório para muitos deles. Embora a operação sem defeitos seja o seuobjetivo, não há garantia de que sistemas de software vão estar livres de falhas e de seusefeitos ao longo do seu tempo de operação. A fim de proporcionar confiabilidade, apesarda presença de falhas, técnicas de tolerância a falhas devem ser adotadas. Quando háuma falha no sistema, a manifestação desta falha pode dar origem a erros. Estes, porconsequência, podem resultar em defeitos. O objetivo da tolerância a falhas é evitar

6

2.1. TOLERÂNCIA A FALHAS

falhas e erros com o intuito de levar o sistema a um estado livre de erros. Vários autoresapresentaram suas próprias classificações para as técnicas de tolerância a falhas. A maiscomum é a classificação em quatro fases de aplicação [75]: detecção, confinamento,recuperação e tratamento.

Detecção de erros

O ponto inicial para todas as estratégias de tolerância a falhas é a detecção de um erro.Antes de ser detectada, uma falha se manifesta como um erro. Antes de sua manifestaçãocomo erro, a falha encontra-se em um estado de latência e assim não pode ser detectada.Enquanto uma falha não pode ser diretamente detectada, a manifestação da falha poderágerar estados de erro em algum lugar do sistema [75]. A existência da falha pode estarpresente em um sistema sem nunca se manifestar.

Confinamento de erros

Devido ao atraso entre a manifestação da falha e a sua detecção, informações erradaspodem se espalhar no sistema. O confinamento é uma técnica que restringe limites paraa propagação das informações erradas. Na elaboração de sistemas devem ser previstasrestrições ao fluxo de informações para evitar fluxos acidentais e estabelecer interfacesde verificação para detecção de erros.

Recuperação de erros

Figura 2.1 Recuperação por avanço e retrocesso [74].

Esta técnica é responsável por substituir um estado errôneo por um estado livre deerros com o objetivo de permitir a sua recuperação. Esta substituição pode ocorrer de

7

2.2. TRATAMENTO DE EXCEÇÕES

duas maneiras distintas conforme a Figura 2.1 :

• Recuperação por retrocesso: consiste na passagem do estado do sistema para umestado consistente já ocorrido.

• Recuperação por avanço: procura um novo estado livre de erros que permita aosistema proceder com sua execução. Nesta maneira, somente é permitido a recu-peração de erros os quais os danos podem ser antecipados.

2.1.4 Tratamento de falhas

A fase de tratamento de falhas é responsável por localizar a falha e recuperar o sistemapara um estado livre de erros. Nesta fase, a falha é primeiramente isolada para depois serreparada. O procedimento do reparo depende do tipo da falha. Falhas permanentes re-querem que um componente falho seja substituído por outro componente. A localizaçãoda falha é realizada em duas etapas [74]: localização rápida, aplicada sobre um móduloou subsistema e localização fina, mais demorada, onde o componente falho é determi-nado. Nas duas formas de localização são usados testes de diagnóstico (teste realizadocomparando resultados gerados com os resultados previstos) e pode ser conduzido nosistema de forma manual ou automática [74]:

• Diagnóstico manual: executado por um operador local ou remoto;

• Diagnóstico automático: executado pelos componentes livres de falha do sistema.

Após a localização da falha, o componente danificado é removido com o objetivo dereparar a falha do sistema. A restauração pode ocorre de maneira manual ou automática.

2.2 Tratamento de ExceçõesSistemas devem ser bem estruturados com o objetivo de serem tolerantes às manifesta-ções de falhas em seus componentes. Desta forma, para lidar com esta complexidadeadicional, tratamento de exceções provê um arcabouço para a estruturação de aplicaçõestolerantes a falhas. Esta técnica permite uma clara separação entre as atividades normaise excepcionais em um sistema de software.

Um sistema de software consiste em um conjunto de componentes que interagementre si para prover as demandas do ambiente do sistema [75]. Estes componentes rece-bem requisições de serviço e produzem respostas. Caso o componente responsável pela

8

2.2. TRATAMENTO DE EXCEÇÕES

resposta não consiga atendê-la, devolve uma exceção ao componente que requisitou. Asrespostas são classificadas em duas categorias: respostas normais e respostas excepcio-nais [25]. A atividade normal implementa os serviços normais do componente, enquantoa atividade excepcional provê mecanismos para tolerar as falhas que causam exceções.Exceções pode ser classificadas em três categorias:

• Interface exception: sinalizada em resposta a uma requisição que não está emconformidade com a interface do componente requisitado.

• Failure exception: sinalizada se um componente por algum motivo não pôde pro-ver o serviço especificado.

• Internal exception: são exceções lançadas pelo componente com o intuito de invo-car seu próprio mecanismo de tolerância a falhas. Neste mecanismo, o tratador daexceção é responsável por trocar o fluxo de controle para o seu estado normal.

Esta técnica estrutura o código de recuperação de erros de um sistema para que estespossam ser mais facilmente detectados, sinalizados e manipulados. Muitas linguagensde programação incorporam essa técnica. Elas fornecem construções para sinalizar aocorrência de um erro e um conjunto de medidas de recuperação [6]. O mecanismode tratamento de exceções é responsável por alterar o fluxo normal de controle em umprograma para seu fluxo excepcional na ocorrência de uma exceção. No âmbito das lin-guagens de programação que implementam este mecanismo, exceções podem ser classi-ficadas [10] em duas categorias:

• Definida pelo usuário: as exceções são definidas e detectadas no nível da aplica-ção.

• Predefinida: estas exceções são declaradas implicitamente e são associadas a con-dições detectadas em tempo de execução pela linguagem de programação.

Os tratadores de exceções são inseridos em uma região particular do código normal,denominada de região protegida. Cada região protegida pode ter associado um conjuntode tratadores. Sendo assim, se uma exceção é lançada em uma região protegida, o fluxode controle normal é desviado para o fluxo de controle excepcional.

A Figura 2.2, ilustra três regiões protegidas. Cada uma destas pode ter um conjuntode tratadores associados. Caso alguma exceção ocorra em um dos blocos protegidos,o fluxo excepcional segue para o tratador compatível com a exceção sinalizada. Nesta

9

2.3. TRATAMENTO DE EXCEÇÕES EM JAVA

Figura 2.2 Mecanismo de Tratamento de Exceções

figura, a execução que inicia no bloco main segue seu fluxo para o método m1() quepor sua vez faz chamada ao método m2(). Na execução de m2(), o mecanismo deexceção sinaliza uma exceção do tipo E1 e procura um tratador apropriado (neste caso,o tratador está associado à região protegida do método m1(). Após o tratamento nobloco catch que captura E1 no método m1(), o fluxo segue para a próxima linha logoabaixo da chamada a m1() em main().

2.3 Tratamento de Exceções em JavaEm Java, exceções são objetos de tipos herdados de uma classe especial chamadaThrowable. A hierarquia de classes abaixo de java.lang.Throwable é divi-dida imediatamente em Error e Exception (Figura 2.3). Exceções podem ser che-cadas ou não checadas. Uma exceção é denominada checada quando deve ser tratadaou propagada explicitamente no programa. Já uma exceção não checada não obriga aoprogramador tratar ou propagar uma exceção. Esta categoria representa erros internosda linguagem Java ou erros de programação. O primeiro corresponde aos erros inter-nos e indisponibilidade de recursos em tempo de execução apresentados pela máquinavirtual Java. Esses tipos de exceções são derivados da classe Error e não devem serlançados explicitamente pelo programador. O segundo diz respeito aos erros de progra-mação. Exceções associadas a tais erros são instâncias de tipos derivados da exceçãoRuntimeException, como:

• Divisão por zero (AritimeticException)

• Tentativa de acessar objetos nulos (NullPointerException)

10

2.3. TRATAMENTO DE EXCEÇÕES EM JAVA

• Passagem de argumentos inválidos (InvalidArgumentException)

• Acesso a possições de arrays fora do limite (ArrayIndexOfBounds)

• Conversão explícita de tipos indevida (ClassCastException)

Figura 2.3 Hierarquia de exceções em Java .

Em Java, é denominado escopo protegido (ou contexto de tratamento de exceções[75]) o conjunto de instruções contidas dentro do bloco try. Este bloco pode ter zeroou mais cláusulas catch associadas. Cada cláusula catch declara um tipo de exceçãocorrespondente ao tipo do erro que vai ser tratado. Blocos try-catch podem ser ani-nhados irrestritamente. Um bloco finally é executado sempre, independentementeda ocorrência de uma exceção no bloco protegido. No trecho de código abaixo podemosvisualizar a construção básica do bloco try-catch:

try {

//Sequência de instruções que podem lançar exceções.//Se ocorrer uma exceção do tipo Exception

//ou qualquer subtipo desta classe, o fluxo de

//controle da execução segue para o bloco//catch no ponto onde a exceção ocorreu.

} catch (Exception e) {

//código de recuperação do erro.//pode conter outros blocos protegidos

} finally {//este bloco sempre é executado

//independentemente da ocorrência de uma exceção

}

11

2.4. TESTE DE SOFTWARE

Antes que uma exceção seja capturada, em algum local do código do programa oufora dele, é necessário que esta exceção seja lançada. A exceção lançada pode ser prove-niente do seu próprio componente, de um componente externo ou até mesmo da máquinavirtual Java. Independentemente de onde a exceção é originada, esta é lançada através dainstrução throw. O trecho de código abaixo demostra o lançamento de uma exceção dotipo InvalidUserException na linha 5. Um método pode lançar uma exceção aoencontrar uma situação a qual não possa lidar, ou seja, o método propaga a exceção atéachar um tratador adequado para a exceção lançada. Para isso o método deve informaro tipo de exceção ao qual deseja propagar. Na linha 1 do exemplo abaixo, a exceçãodo tipo InvalidUserException é repassada para o método que fez a chamada arequestUserInfo.

1- public void requestUserInfo() throws InvalidUserException{2- if (user.activeUser()) {

3- user.showInfo();

4- else {5- throw new InvalidUserException();

6- }

7- }

Exceções podem ser levantadas em qualquer ponto de um programa e, se não fo-rem capturadas, podem ser propagandas de forma transparente ao ponto de entrada doprograma, fazendo com que a o programa encerre a sua execução de forma inesperada.

2.4 Teste de SoftwareA construção de um sistema computacional pode ser uma tarefa bastante complexa, de-pendendo das suas características e dimensões [46]. Devido a este fator, um sistemacomputacional está sujeito a diversos tipos de problemas tornando-o diferente do quefoi originalmente projetado. Diversos problemas podem estar relacionados, o mais co-mum é o fator humano [46]. As atividades de engenharia de software dependem muitodas habilidades e conhecimento técnico dos engenheiros de software bem como a inter-pretação da especificação, e por fim, a implementação gerada a partir do entendimentoda especificação.

Teste de software é um processo que consiste em executar um sistema com o objetivode encontrar defeitos [35]. Atividades de validação, verificação e testes de sistemas sãoutilizadas com o objetivo de obter um produto mais próximo ao que foi especificado.

12


Durante a construção, as suas partes assim como o sistema como um todo são testadoscom o objetivo de verificar a sua conformidade com a sua especificação. Se o sistemaexibe algum tipo de divergência, torna-se necessária a realização de correções no sistema,no processo do desenvolvimento ou na sua especificação.

2.4.1 Estratégia de teste

Uma estratégia de teste deve lidar com testes de unidades visando verificar se uma pe-quena parte do código escrito foi desenvolvida de acordo como especificado, com testesque envolvem a integração de partes do sistema e com testes para o sistema como umtodo, para validar os requisitos do cliente. As estratégias podem ser divididas em quatrofases distintas: teste de unidade, teste de componentes, teste de integração e teste desistemas [7].

Teste de Unidade

Teste de unidade verifica se uma porção do código fonte realiza adequadamente a funcio-nalidade proposta isoladamente do restante do sistema[46]. Devido a esta característicageralmente necessita de drivers e stubs. Um driver é um elemento que aplica os casosde teste. Ele é responsável por fornecer os dados de entrada, coletar os dados de saídae apresentá-los ao usuário. Já o stub serve para substituir os módulos necessários quenão estejam disponíveis, com o objetivo de simular o seu comportamento, para a exe-cução da unidade. Isso permite que o código relativo à unidade a ser testada possa serverificado isoladamente.

Teste de Componente

Um componente é uma unidade de composição com interfaces bem definidas. Nestafase o componente é testado de acordo com as especificações das funcionalidades e desua estrutura [36]. Para esta técnica a utilização de drivers e stubs pode ser necessária.

Teste de integração

Uma vez testados os componentes individuais, estes devem ser integrados para criar sis-temas parciais ou completos. Este processo de integração envolve construir o sistema etestá-lo quando a problemas relacionado a sua integração. Nesta fase são realizados tes-tes de integração a fim de testar erros decorrentes deste cenário. Estes visam descobrirerros arquiteturais relacionados às interfaces dos componentes[46]. As três abordagens

13


principais de testes de integração são: big bang, top-down e botton-up. No big bang, to-dos os componentes são integrados de uma só vez não sendo necessário o uso de driverse stubs. Porém nesta abordagem torna-se difícil a localização das falhas. Na aborda-gem top-down os componentes são integrados a partir do bloco principal do programa,não sendo necessários os drivers, porém stubs podem ser necessários. Na abordagembottom-up, os componentes são integrados a partir dos componentes independentes, dis-pensando o uso de stubs. Neste caso novos drivers devem ser criados a cada integração.

Teste de Sistemas

Teste do sistema é o processo com o objetivo de verificar se o programa, como umtodo, não atende aos seus objetivos. Tem utilidade limita se não existe um conjuntode objetivos mensuráveis para o produto[36]. Os testes de sistemas se baseiam nosrequisitos funcionais e não funcionais do sistema.

2.4.2 Teste estrutural

A técnica estrutural estabelece os requisitos de teste com base em uma dada implemen-tação, requerendo a execução de partes ou de componentes elementares do programa[36]. Esta técnica baseia-se na estrutura do programa e permite que seja examinada asua estrutura interna. Nessa técnica os aspectos de implementação são fundamentaisna escolha dos casos de teste. Em geral, a maioria dos critérios da técnica estruturalutiliza uma representação de Grafo de fluxo de controle CFG [36]. Um grafo de fluxode controle G = (N,E,s) é um grafo dirigido que consiste de um conjunto N de nós, umconjunto E de arestas dirigidas e um nó de entrada s. Os nós representam comandosou uma coleção de comandos sequenciais e as linhas ou arestas representam o fluxo decontrole. O grafo de fluxo possui nós de entrada, nos quais a computação começa, e nósde saída cuja, terminando a computação.

Os critérios pertencentes a esta técnica são classificados com base na complexidade,no fluxo de controle e no fluxo de dados [46]. Os Critérios baseados no fluxo de con-trole utilizam informações do grafo de fluxo de controle para derivar os requisitos detestes. Os critérios baseados em fluxo de controle mais conhecidos são Todos-Nos,Todas-Arestas e Todos-Caminhos. O critério baseados em fluxo de dados utiliza in-formações do fluxo de dados pra derivar os requisitos de teste. Para isso é necessárioadicionarão grafo de fluxo de controle informações a respeito do fluxo de dados, carac-terizando o Grafo Def-Uso [67] . Os principais critérios baseados em fluxo de dados

14


são [67]: Todas-Definições, Todos-C-Usos, Todos-P-Usos, Todos-Uso, Todos-C-Usos,Todos Caminhos-DU, Todos-Caminhos-DU, Todos-Potenciais-Uso.

2.4.3 Teste Funcional

Esta técnina checa se um programa está de acordo com a sua especificação, independen-temente do código fonte. Teste funcional é também conhecido como teste caixa-preta outeste comportamental. Ao se testar um sistema computacional (S) são escolhidos algunspontos específicos do domínio do sistema D(S) para a execução de (S) [46]. Idealmente,os testes devem ser realizados para todos os elementos do domínio do sistema. Porémesta ação torna-se bastante custosa. Devido a esta limitação, faz-se necessária a adoçãode critérios de seleção dos elementos do D(S) com o objetivo de obter um conjunto re-duzido com alta probabilidade de revelar uma falha. Estes critérios visam estabelecercondições que devem ser satisfeitas no decorrer dos testes.

Os critérios de teste funcionais são utilizados para se projetar casos de testes os quaiso programa ou sistema é considerado caixa preta [46]. Os detalhes internos não são con-siderados na execução dos casos de teste. Para testar o sistema, são fornecidas entradas eavaliadas as saídas geradas para verificar se estão em conformidade com a especificação.As fontes utilizadas pelos testes funcionais são as especificações de requisitos e de pro-jeto. As abordagens mais conhecidas desta técnica são: Particionamento de equivalência,Análise do Valor Limite, Grafo Causa-Efeito e Error-Guessing.

Particionamemnto de equivalência

Técnica utilizada para a escolha de dados de entrada para testes[46]. O domínio deentrada é dividido em classes de equivalência, que representam um conjunto de valoresválidos ou inválidos para as condições de entrada.

Análise do Valor Limite

Técnica utilizada para escolha de dados de entrada, combinada com a técnica de parti-cionamento de equivalência. Como grande número de erros tende a ocorrer nos limitesdos valores de entrada, a técnica de análise de valores limite determina que os dados deentrada escolhidos sejam valores limite de cada uma das classes de equivalência[46].

15

2.5. JUNIT

Grafo Causa-Efeito

Esse critério de teste verifica o efeito combinado de dados de entrada. As causas, condi-ções de entrada, e os efeitos, ações, são identificados e combinados em um grafo a partirdo qual é montada uma tabela de decisão, e a partir desta, são derivados os casos de testee as saídas. Esta técnica descreve o comportamento do sistema em forma de elementos eos relacionamentos entre eles[36]. Existem várias formas de representar o sistema comoum grafo, por exemplo, modelo de fluxo de transações (do inglês Transaction flow modelTFM) e máquina de estado finitos[7]. Por ser uma técnica para a geração de casos deteste, pode ser utilizada em conjunto com técnicas para a geração de dados de entrada.

Error-Guessing

Consiste em uma técnica ad-hoc na qual a pessoa pratica inconscientemente, uma técnicapara projetar casos de testes, supondo por intuição ou experiência alguns tipos prováveisde erros e, a partir disso, definem-se casos de testes que poderiam detectá-los [36]. Aideia básica é enumerar uma lista de possíveis erros ou situações sujeitas a erros e, emseguida, escrever casos de teste com base nesta lista.

2.5 JUnitFerramentas e técnicas para a realização de testes automatizados de software contribuempara o controle da execução dos testes e auxilia na comparação dos resultados espera-dos em comparação aos resultados obtidos pela execução do programa testado. Atravésdestes testes, é possível configurar as precondições e outras funções de controle e obterrelatório dos testes. JUnit [18] rapidamente tornou-se o framework padrão para o desen-volvimento de testes de unidade em Java. Este framework foi criado por Eric Gamma eKent Beck, com suporte à criação de testes automatizados na linguagem de programaçãoJava.

Esta seção se destina a apresentar parte das funcionalidades deste framework. Em-bora seja possível o uso de qualquer funcionalidade do JUnit na abordagem posposta,no restante deste tópico iremos abordar apenas as construções necessárias para o en-tendimento da extensão criada para dar suporte a testes do comportamento excepcional.Sendo assim maiores detalhes dobre o jUnit podem ser encontrados no site do projeto1

bem como informações sobre o projeto e arquitetura2.1http://www.junit.org2http://junit.sourceforge.net/doc/cookstour/cookstour.htm e http://junit.sourceforge.net/doc/

16

2.5. JUNIT

Um caso de teste é responsável por especificar um conjunto de entradas de teste,condições de execução e resultados previstos, com a finalidade de fazer a avaliação dealgum aspecto particular de um cenário a fim de verificar se o componente testado estáfuncionando de acordo com as suas especificações [36].

No JUnit 4, podemos construir um caso de testes definindo um ou mais testes. Paraisso é usada a anotação @Test nos métodos responsáveis por testar partes do código emum sistema. O trecho de código abaixo mostra um teste em JUnit:

public class MeuCasoDeTeste {

@Testpublic void testMeuTeste() {

Soma soma = new Soma();

assertEquals(30, Soma.somar(15,15), 0);}

}

Neste caso de teste o método testMeuTeste() verifica se o retorno da soma (método Soma.somar(int, int) ) é igual ao valor esperado. JUnit permite agruparos casos de testes em suites de testes através da anotação @SuiteClasses.

@RunWith(Suite.class) //Indica que está classe está associada a uma//suíte de teste (Suite.class)

//Casos de testes que devem ser executados@SuiteClasses({ TC01.class, TC02.class, TC03.class})

public class AllTestsInjection02 {}

Esta Suite de testes agrupa os casos de testes TC01, TC02 e TC03. Todos os testescontidos nesses casos de testes serão executados.

Através da anotação @Before é possível executar um ou mais blocos de códigoantes da execução do caso de teste. Pode-se também, após a execução deste, executarcomandos através de métodos anotados por @After. A anotação @Before permiteiniciar objetos e executar todos os pré-requisitos para que as condições iniciais do testesejam atendidas. Já a anotação @After serve para liberar os recursos alocados. O testeanterior pode ser escrito novamente da seguinte maneira:

public class MeuCasoDeTeste {

Soma soma = null;

@Before

17

2.5. JUNIT

public void setUp() {

soma = new Soma();

}

@Testpublic void testMeuTeste() {

Soma soma = new Soma();

assertEquals(30, Soma.somar(15,15), 0);}

@Afterpublic void releaseResources() {

soma = null;

}}

Neste caso de teste, no método setUp é criado o objeto do tipo Soma necessáriopara o teste testMeuTeste. Por sua vez, no método releaseResources o atri-buto soma é desalocado.

Os resultados dos testes são obtidos através da comparação entre os resultados espe-cificados e os resultados verificados no processamento de um determinado dado. Em JU-nit esta comparação é realizada utilizando-se os métodos da classe Assert. O métodoassertTrue verifica se uma condição é verdadeira, assertFalse verifica se umacondição é falsa, assertEquals verifica se dois objetos são iguais, assertNotNulverifica se um objeto não é nulo, assertNull verifica se um objeto é nulo, assertSameverifica se dois objetos possuem a mesma referência, fail serve para falhar um casode teste . Para todos estes, caso a condição não seja atendida, uma exceção do tipoAssertionFailedError é lançada.

JUnit também permite verificar se uma determinada exceção esperada de fato foilançada na execução de um caso de teste, como pode ser observado no exemplo abaixo.

@Test(expected=IOException.class)

public void testMeuTeste() {Classe.metodo();

}

Este teste verifica se há ocorrência de uma exceção do tipo IOException na exe-cução do teste. Se a exceção ocorrer o teste passa, caso contrário o teste falha.

18

2.6. TEST-DRIVEN DEVELOPMENT

2.6 Test-Driven DevelopmentTest-Driven Development (TDD) [38] é uma técnica de desenvolvimento de softwareque vem ganhando atenção com a popularidade das metodologias ágeis de desenvolvi-mento de software. É uma das técnicas mais utilizadas em Extreming programming(XP)e outras metodologias de desenvolvimento ágil. TDD consiste em ciclos rápidos de tes-tes, codificação e refatoração. Ao adicionar uma funcionalidade, vários destes ciclos sãoexecutados com pequenas tarefas objetivando implementar e aperfeiçoar o sistema desoftware até que não haja mais nada a acrescentar e mais nada a tirar [37]. Pesquisasapontam que esta prática reduz a incidência de defeitos [17]. Quando usada correta-mente, esta técnica também ajuda a melhorar o projeto do sistema, documenta as interfa-ces públicas e protege, através dos testes automatizados, contra erros futuros [17]. TDDexige que os testes automatizados sejam escritos antes do código funcional.

2.6.1 Etapas do TDD

Passo 1: Pensar

TDD utiliza testes pequenos para forçar o desenvolvedor a escrever seu código funcional.É recomendado que ele escreva somente o código necessário para que o teste passe. Deacordo com os conceitos de XP, não devemos escrever nenhum código de produção amenos que um teste falhe. O primeiro passo consiste em imaginar o comportamento queo código deverá apresentar sempre quebrando em atividades bastante pequenas. Apósesta atividade pensa-se em um teste pequeno que irá falhar a menos que o comporta-mento esteja presente. Este teste irá forçar a criação do código funcional referente aocomportamento desejado. Como exemplo, vamos pensar em um sistema que necessitelidar com números de CPF. Neste caso é necessário a criação de uma classe que repre-sente um CPF. O número do CPF deve ser passado como parâmetro do construtor. Casoeste seja inválido, uma exceção do tipo IllegalArgumentException deverá serlançada. Este é primeiro passo de imaginar o comportamento desejado.

Passo 2: Barra vermelha

Neste passo deve ser escrito o código de teste, o mínimo necessário. Janzen et al [17]recomendam que os testes não passem de cinco linhas, caso possível. Inicialmente co-difique em termos das classes e suas interfaces públicas, não levando em conta a im-plementação interna desta classe. Os primeiros testes serão escritos com o objetivo de

19

2.6. TEST-DRIVEN DEVELOPMENT

usar nome de classes e métodos que não existem ainda, forçando o programa a projetara interface da classe da perspectiva do usuário da classe e não do seu comportamentointerno. Após o teste ser codificado, deve ser executada a suíte de testes. Se o teste nãofalhar, ou se ele falhar de uma maneira diferente da esperada, algo está errado. Estaetapa é chamada de barra vermelha, pois na maioria das ferramentas, os testes que nãopassam resultam em uma barra vermelha. Exemplo:

@Test(expected= IllegalArgumentException.class)public void testVerifyCpf() {

Cpf cpf = new Cpf(00000000000);

}

O código não compila devido ao teste preceder a implementação da entidadeCpf.Tendo em vista isto, devemos criar esta classe.

public class Cpf {

public Cpf(int cpfNumber) {}}

Agora o teste compila mas o teste ainda não passa como esperado, já que a lógica docódigo funcional não está completa.

Passo 3: Barra verde

O próximo passo consiste em escrever o código funcional, apenas o suficiente para oteste passar. Neste momento não é necessário a preocupação com a elegância do código.Após a escrita do código, os testes devem ser executados novamente. Neste momentotodos os testes devem passar, sinalizando aderência à especificação dos testes. Se o testefalhar, o código deverá ser corrigido ou reescrito dependendo de sua complexidade.

Exemplo: Para que o teste passe, é necessário adicionar o cálculo de verificação doCPF e caso este não seja válido, uma exceção deverá ser lançada.

public class Cpf {

int number;

public Cpf(int cpfNumber) {if (!isValid()) {

trows new IllegalArgumentException();

} else {this.number = cpfNumber;

}

20

2.7. PROGRAMAÇÃO ORIENTADA A ASPECTOS

}

private boolean isValid(){...}; //Logica de verificação}

Passo 4: Refatoração

Após todos os testes passarem é hora da refatoração. Nesta etapa, deve ser examinado ocódigo identificando melhorias. Para cada ponto identificado, o código deve ser refato-rado trabalhando em uma série de pequenas melhorias. Após cada refatoração, executenovamente os testes para verificar se as modificações não geraram efeitos colaterais fa-zendo com que os testes não passem mais. Se após a refatoração o teste não passou, érecomendado restaurar o código anterior à mudança. Esta etapa se restringe à melho-ria do código existente. Novas funcionalidades são desaconselhadas. Para uma novafuncionalidade o processo deverá ser seguido desde o passo 1, seguido do teste de falha.

Exemplo: Melhorias de código podem ser realizadas (ex: melhoria do algoritmo devalidação de cpf ou remoção de redundâncias):

1 public Cpf(int cpfNumber) {2 if (!isValid()) {

3 trows new IllegalArgumentException();

4 }5 this.number = cpfNumber;

6 }

Neste caso, a cláusula else não é necessária pois caso haja uma o lançamento deuma exceção (linha 3), nenhuma instrução abaixo da linha 3 será executada.

Passo 5: Repetir

Quando você estiver pronto para adicionar um novo comportamento, inicie o ciclo no-vamente. Ao final do ciclo você obterá um código bem testado e com o design bemdefinido.

2.7 Programação Orientada a AspectosAs primeiras ideias sobre separação dos interesses foram apresentadas por Dijkstra [80]Este trabalho seminal tinha como principal finalidade separar um sistema operacional em

21


partes menores com o intuito de entender melhor cada parte isoladamente e tornar possí-vel desenvolvê-las separadamente. Um interesse consiste em uma parte do sistema quedeverá ser tratada como uma unidade conceitual. De forma geral, os vários interesses dosistema devem ser separados em módulos de acordo com as abstrações do desenvolvi-mento de software. Essas ideias foram refinadas por Parnas [43]. Este último estabeleceuque o critério fundamental para se quebrar sistemas em módulos consiste na ocultaçãode informações (em inglês: Information Hiding). Desse modo, o desenvolvimento passaa ser centralizado em interfaces abstratas ao invés de detalhes de implementação.

Programação Orientada a Aspectos é um paradigma cuja intenção é prover a sepa-ração explícita de interesses transversais [77], funcionalidades de um sistema que sãodifíceis de isolar e cuja implementação estende-se através de diferentes módulos. Esta se-paração é realizada através de uma nova unidade de modularização denominada aspecto[45]. Logging, persistência e tratamento de exceções são exemplos típicos de interessestransversais. Este paradigma propõe que sistemas são melhor implementados com a se-paração de vários interesses em diferentes unidades de implementação. Essas unidadessão combinadas através de uma ferramenta chamada aspect weaver (ou simplesmenteweaver). Um sistema orientado a aspectos contém código base (implementação dosinteresses não transversais) e aspectos (interesses transversais).

2.7.1 Pontos de Junção

Um ponto de junção é um ponto em um programa onde interesses transversais interagemcom os não-transversais. Este define um ponto específico na execução do programa.Podemos citar como pontos de junção, chamada e execução de um método, a ocorrênciade uma exceção, entre outros.

A Figura 2.4 exemplifica um fluxo de execução entre dois objetos identificando seuspontos de junção. Podemos identificar como o primeiro ponto de junção a invocaçãoa um método em Object A. Este método pode levantar alguma exceção ou retornarda sua execução com sucesso. O segundo ponto de junção consiste na execução destemétodo que também poderá retornar sem erros ou levantar uma exceção. No decorrerda execução do método do primeiro objeto, há a invocação de um método em Object

B. Está invocação, assim como a execução deste método, também são pontos de junçãoque podem retornar sem erros ou levantar algum tipo de exceção.

22


Figura 2.4 Join points de um fluxo de execução [28]

2.7.2 Aspectj

Aspectj é uma extensão orientada a aspectos da linguagem Java. É a linguagem orien-tada a aspectos mais popular, além de ser a primeira a ser proposta. Já foi empregadaem vários estudos sobre orientação a aspectos. Neste trabalho utilizamos Aspectj paramonitorar as exceções que trafegam no decorrer da execução do sistema e forçar o seulançamento quando o desenvolvedor considerar isso necessário.

Sintaxe básica do Aspectj

POINTCUTS: Pointcuts são construções de AspectJ que permitem a seleção de um con-junto de pontos de junção. Pointcuts também permitem que o contexto relativo aospontos de junção selecionados seja exposto para os advice associados a eles. Com a uti-lização de pontos de junção, é possível obter argumentos de métodos, exceções lançadasno ponto de junção e objetos usados como alvo para chamadas de métodos. Os pontosde junção selecionados podem ser combinados através dos operadores de intersecção deconjuntos (&&), união de conjuntos (||) ou negação(!). Para a definição dos pointcuts,podemos utilizar, por exemplo, os seguintes designadores da tabela 2.7.2. Podemos uti-lizar wildcards para representar tipos de retorno, nomes ou parâmetros associados a umconjunto de pontos de junção selecionado. Os seguintes caracteres definem esses wild-cards: o ” * ” indica qualquer tipo de elemento, ” .. ” aparece em listas de parâmetros eindica qualquer seqüência independentemente do tipo de objeto, e ”+ ” é utilizado depoisdo nome de um tipo para indicar que os seus subtipos também estão sendo selecionados.Alguns exemplos de pointcuts são apresentados a seguir.

pointcut callexecutionGeneral(): handler(Throwable+)

&& !within(br.cin.ufpe.junite.*);

23


Categoria do Ponto de Junção SintaxeExecução de método execution(MethodSignature)Chamada a método call(MethodSignature)

Execução do construtor execution(ConstructorSignature)Chamada ao construtor call(ConstructorSignature)Inicialização da classe staticinitialization(TypeSignature)Acesso ao atributo get(FieldSignature)

Atribuição a um atributo set(FieldSignature)Execução de tratador de exceções handler(TypeSignature)Inicialização de objetos initialization(ConstructorSignature)

Pré-inicialização de Objetos preinitialization(ConstructorSignature)Execução do advice adviceexecution()

Tabela 2.1 Desiginadores de ponto de junção [45] pg.74

pointcut tc(): execution( void

atunes.kernel.utils.PictureExporter.doExport(..));

No primeiro exemplo, o pointcut intercepta o tratamento de qualquer exceção do tipoThrowable ou subtipo que não esteja em nenhuma classe do pacotebr.cin.ufpe.junite. Esse pointcut também captura o argumento passado parao método (args(s)), neste caso a exceção tratada, permitindo que seja exposto posterior-mente aos advice. No segundo exemplo, são capturadas chamadas ao métododoExport() da classe PictureExporter que não devolve nenhum resultado e tem zero oumais parâmetro de qualquer tipo.

Advice

Advice são estruturas que permitem que o código seja associado a um conjunto de pontosde junção selecionados. O Advice pode usar informação contextual relativa aos pontosde junção selecionados, se esta for exposta pelos pointcuts. AspectJ define três tipos deadvice: before, after e around. A Figura 2.5 fornece exemplo de uso de cada um deles.Neste trabalho, são empregados apenas advice do tipo around.Advice around: Este tipo de advice é executado no lugar do ponto de junção selecio-

nado. Pode capturar ou executar o ponto de junção inúmeras vezes com possibilidade depassar diferentes argumentos em cada uma dessas execuções. Dentro do advice usamosa instrução proceed() para executar o ponto de junção originalmente selecionado. Aslinhas 23 a 30 exemplificam o uso do advice around para tratar exceções. A chamada

24


1 - pointcut myPointcut(): execution(void Class.method());2 -3 - before(): myPointcut() {4 - //Antes da execução de method()5 - //faz alguma coisa.6 - }7 -8 - after(): myPointcut() {9 - //Depois da execução de method()10- //faz alguma coisa.11- }1213- after()returning: myPointcut() {14- //ao retornar sem erros da execução15- //realiza alguma ação16- }17-18- after() throwing : myPointcut(){19- //Realiza alguma ação após method()20- //lançar uma uma exceção de qualquer tipo21- }22-23- void around(): myPointcut(){24- //Substitui a execução de method()25- try {26- f = proceed(); //Executa o corpo original de method()27- } catch (IOException e) {28- ...29- }30- }

Figura 2.5 Exemplo de advice em AspectJ

que representa a condição do ponto de junção é capturada pelo pointcut myPointcute executada através do comando proceed(). Se levantar alguma exceção, o fluxo decontrole segue para o bloco catch, após isto, retorna para o ponto posterior à capturado ponto de junção.Intertype declarations Além de modificar o comportamento de um sistema em

tempo de execução pelo uso de pointcuts e advice, um aspecto pode alterar a estruturaestática dos módulos do sistema através das declarações intertipo (Intertype Declarati-ons). Estas permitem a declaração de membros e relações (atributos, métodos, constan-

25


tes, construtores, exception softening entre outros) que afetam a estrutura e hierarquia deoutros tipos [52]. Como este trabalho tem como foco o tratamento de exceções, vamosnos ater ao comando declare soft.

O comando declare soft faz com que o compilador Java não realize as verifica-ções que normalmente faria, com relação a exceções, no conjunto de pontos de junçãoselecionado. Ele envolve a exceção selecionada com uma exceção não verificada do tipoSoftException. A sintaxe é apresentada na linha abaixo.

declare soft : Type : Pointcut ;

Os trechos de código abaixo apresentam exemplos do emprego dessa construção:

declare soft : IOException : execution(Classe.metodoX(..));

declare soft : XException : call(Classe.new(..));

No primeiro exemplo, a exceção IOException não precisa ser tratada dentro daexecução do método metodoX() da classe Classe pois, através deste comando, ocompilador Java não irá verificá-la. Algum outro ponto do programa deverá tratar umaexceção do tipo SoftException. No segundo exemplo temos uma construção similar.A exceção XException não precisa ser tratada na chamada ao construtor da classeClasse pelo mesmo motivo.

26

3Abordagem Proposta

Este capítulo tem por objetivo descrever a abordagem proposta. Esta permite o teste docomportamento excepcional possibilitando especificar e verificar os fluxos excepcionaispercorridos a partir dos pontos onde são lançados até o seu destino. Também apresenta-mos um exemplo ilustrativo para apontar algumas limitações no uso de casos de testeselaborados através do JUnit referentes à detecção de erros de tratamento de exceções.

3.1 MotivaçãoConsidere um sistema de informação dividido em três camadas (figura 3.1). A camadade Dados, responsável pela lógica e comunicação com o banco de dados; Negócio, res-ponsável pela logica da aplicação e GUI responsável pela lógica de apresentação. Nestesistema, as exceções levantadas pelo DAO (Data Access Objects), na camada de dados,são subtipos de DAOException e representam problemas relacionados à tentativa deacesso ao banco de dados. Estas exceções devem ser repassadas e tratadas pelo servletna camada acima (GUI).

Em alguns casos o JUnit silencia o acontecimento de uma exceção. O seguinte casode teste ilustra este problema:

public void testDAOEHPolicy (){Servlet s1 = new Servlet();

s1.service();

}

Se uma exceção do tipo DAOException for lançada no DAO mas não for repas-sadas até o servlet, pode-se ter a sensação que a exceção foi adequadamente tratadapelo Servlet. No entanto a exceção pode ter sido acidentalmente capturada por um

27

3.1. MOTIVAÇÃO

Figura 3.1 Arquitetura em camadas de um sistema de informação

elemento intermediário na cadeia de propagação desta exceção como por exemplo ummétodo da fachada.

Para dar suporte a criação de casos de testes para a verificação da ocorrência de umaexceção o JUnit define a anotação@Test(expected=Exception.class 1.

O caso de teste abaixo define que na cadeia de chamadas do método service()deverá ocorrer o lançamento de uma exceção do tipo DAOException e está deverá serpropagada até o caso de teste.

@Test(expected=DAOException.class)

public void testDAOEHPolicy (){

Servlet s1 = new Servlet();

s1.service();

}

Este teste faz chamada ao método service() do Servlet. O teste espera a ocorrên-cia de uma exceção do tipo DAOException e caso não ocorra o teste falha.

1http://junit.sourceforge.net/doc/faq/faq.htm#tests_8

28

3.1. MOTIVAÇÃO

Esta abordagem também é limitada porque pode esconder erros sutis. Por exemplo,se um componente sinaliza uma exceção que representa um erro de programação masessa exceção é capturada por um tratador genérico. Podemos exemplificar esta situaçãocom exemplo abaixo:

public void update(Entity entity) throws DAOException {

try {...

//neste momento entity é nulo

//gerando NullPointerExceptionEntityData data = entity.getData()

...} catch (Exception e) {

throw new DAOException();

}}

Neste trecho de código, se o objeto passado como parâmetro (entity) for nulo, nachamada ao métodogetData() é obtida uma exceção do tipoNullPointerException.Esta, por sua vez, é capturada pelo tratador genérico e uma exceção do tipoDAOExceptioné propagada à cadeia de chamadas do método update. O teste elaborado para este tre-cho de código utilizando o JUnit irá passar e o erro de programação será mascarado.Observamos neste estudo através dos sistemas avaliados (capítulo 4) erros desta natu-reza.

O JUnit não fornece uma maneira de verificar se um elemento intermediário errone-amente lida com a exceção. Isso é compreensível, uma vez o JUnit visa apoiar testesde unidade. Porém, a propagação global de exceção de forma inesperada pode ser umagrande fonte de erros [57, 55]. Este problema é particularmente visível para linguagenscomo Java e C#, onde exceções são objetos que podem ser capturados por seus superti-pos [55], isto é, um tratador de exceção para um tipo de T captura exceções de qualquertipo T ! que é um subtipo de T .

JUnit é o padrão para testes automatizados de software e foi estendido em algunscenários para lidar com escopo mais amplo (por exemplo, testes de integração) [27, 56].Para este trabalho utilizamos o JUnit em um contexto mais amplo. Isso não impede quetestes de unidades sejam criados paralelamente aos testes do comportamento excepcio-nal proposto neste trabalho.

Acreditamos que o tratamento de exceções deve ser levado em conta em todas asfases de desenvolvimento de software [26] e que TDD e métodos ágeis proporcionam

29

3.1. MOTIVAÇÃO

um melhor suporte que um processo baseado em documentação. Consideramos que aabordagem de testes no JUnit deve ser empregada em outros contextos, não somentepara testes de unidade do comportamento normal da aplicação. Tendo em vista tais limi-tações, verificamos a necessidade de uma abordagem para facilitar a definição, criação,execução e verificação de casos de testes referente ao comportamento excepcional. Osrequisitos fundamentais para essa abordagem são:

• Permitir ao desenvolvedor definir os fluxos excepcionais percorridos por uma exce-ção e compará-los com o fluxo excepcional obtido pela execução do sistema. Estefluxo pode ser definido com todos os nós na cadeia de propagação das exceções,ou parcialmente, onde elementos podem ser omitidos. Fluxos excepcionais quedivergem da especificação são considerados erros de implementação referentes aocomportamento excepcional da aplicação.

• Os testes devem ser especificados de modo similar aos testes convencionais doJUnit adicionando as definições dos fluxos excepcionais.

• Devido ao fato dos testes estarem sempre atualizados (caso contrário os testes nãopassam), estes podem ser utilizados como a própria documentação no que se refereaos fluxos excepcionais excluindo a necessidade de manter mais um artefato.

3.1.1 Priorizando os fluxos excepcionais

Em nossa abordagem, casos de teste verificam a aderência do sistema ao seu comporta-mento excepcional especificado. Idealmente os testes devem ser concebidos e executa-dos de forma a exercitar todos fluxos excepcionais disponíveis. Isto porém é impraticá-vel para qualquer sistema não-trivial. Como consequência, torna-se necessária a seleçãode um conjunto reduzido de fluxos excepcionais com alta probabilidade de revelar pro-váveis erros.

Diferentes critérios podem ser utilizados a fim de priorizar os fluxos excepcionais aserem testados. Ao se testar um sistema existente, o desenvolvedor deve escolher umsubconjunto entre todos os fluxos excepcionais disponíveis. Os critérios selecionadosdevem indicar os fluxos com a maior probabilidade de revelar alguma falha. Esses cri-térios podem ser baseados em diferentes fontes de informação tais quais: (i) elementosarquiteturais importantes, como classes que são responsáveis pela comunicação de todauma camada (ponto de acesso da camada); (ii) métricas de código fonte; (iii) Antipa-drões relacionados ao tratamento de exceções [78], padrões de bugs [57], ou fontes

30

3.1. MOTIVAÇÃO

bem conhecidas de erros, ou (iv) o conhecimento específico sobre potenciais problemasrelacionados a à aplicação.

Apesar da elaboração de uma nova abordagem de priorização dos fluxos excepcio-nais a serem testados estar fora do escopo deste trabalho, o restante desta seção fornecealgumas orientações que foram utilizadas para seleção dos fluxos excepcionais para acriação dos casos de testes dos sistemas avaliados apresentados na Seção 4.

A arquitetura de software tem sido reconhecida por muitos autores [21, 32] comoum meio para modelar o comportamento excepcional de sistemas de software. Algu-mas abordagens [21, 31, 42, 51, 65] foram propostas para permitir aos desenvolvedoresdescreverem maneiras pelas quais os componentes podem falhar, as exceções que repre-sentam essas falhas, os tratadores que lidam com tais exceções e como tais exceções vãotrafegar no sistema. Essas informações são geralmente definidas em forma de visão defluxo excepcional [31]. Esta descreve os componentes responsáveis sinalizar ou captu-rar exceções e também os conectores arquiteturais que modelam os fluxos excepcionaisentre os componentes de um sistema. Ferreira et al [31] apresentam uma abordagempara mapear a visão do fluxo excepcional (fluxo excepcional a nível arquitetural) em di-agramas de atividades UML. Essa abordagem pode ajudar o desenvolvedor a identificarfluxos excepcionais passiveis a falha, uma vez que através de diagrama de atividade épossível para representar o fluxo de exceção inter-processual e identificar quais os tiposde exceção são propagadas em uma pilha de chamadas. Este é apenas um exemplo decomo tais visões de alto nível fornecem informações úteis ao se testar fluxos excepcio-nais.

Além disso, certas características relacionadas ao código fonte de em programa de-vem ser levadas em consideração ao se especificar o comportamento excepcional utili-zado casos de teste. A seguir são apresentadas algumas situações consideradas comoantipadrão ou potenciais ocorrências de bugs relacionadas ao tratamento de exceções.

• Blocoscatch nos nais a cláusula catch captura exceções de um tipo genéricocomo Exception ou Throwable.

• Um grande número de instruçõesthrow dentro de uma classe. A justificativa paraisso é que, quanto maior este número, maior o conjunto de fontes de problemasdentro dessa classe. Em particular se este critério se aplicar a um únicométodo. Osfluxos excepcionais que passam por este método são certamente bons candidatos.

• Blocos catch que são utilizados para capturar uma exceção em uma versão an-terior de um sistema que porém não são mas passíveis de serem lançadas em uma

31

3.2. TIPOS DE FLUXOS EXCEPCIONAIS

versão posterior, especialmente se o tipo da exceção possuir subtipos. Sendo as-sim os blocos catch permanecem no código podendo capturar uma exceção nãoesperada. Este caso é denominado tratador obsoleto.

• Tratadores para exceções desencadeadas por operações de entrada e saída (IO).Os problemas relacionados a IO são muito comuns em aplicações modernas e sãoocasionados por diversas razões. Em Java, em particular, todas as exceções querepresentam erros de IO são subtipos de IOException, o que cria um terrenofértil para a captura acidental de exceções.

• Tratadores que remapeiam a exceção capturada em uma exceção de um tipo dife-rente.

• Métodos que encapsulam exceções verificadas em uma exceção não verificada,principalmente se o mesmo tipo de exceção não verificadas são empregadas paratodas as exceções verificadas.

• Métodos cuja a clausula throws permite a propagação de muitos tipos de ex-ceção, especialmente se parte de uma cadeia de invocações dos método tambémapresentam essa característica.

Para o nosso estudo priorizamos a criação dos testes com fluxos excepcionais quepossuíssem estas características. As exceções levantadas e tratadas no mesmo métodoforam desconsideradas. Somente exceções com mais de dois níveis de propagação fo-ram consideradas. Na Figura 3.2 podemos observar exemplos de fluxos candidatos enão candidatos à criação de casos de teste. Nesta figura, círculos na cor branca represen-tam métodos internos ao sistema, círculos na cor cinza representam métodos externosao sistema. Setas cheias representam chamadas entre métodos e setas tracejadas repre-sentam a resposta excepcional. As partes A e B da Figura 3.2 não possuem mais de doisníveis, sendo assim, não são candidatas. Na parte C desta figura temos três níveis, po-rém o terceiro é uma chamada externa ao sistema, neste caso também não é consideradacandidata. Na Figura 3.2 parte D temos um fluxo de três ou mais níveis, sendo assimcandidato à criação de um caso de teste.

3.2 Tipos de fluxos excepcionaisA especificação do fluxo excepcional esperado pode usar a semântica de fluxo mínimoou completo. A Figura 3.3 ilustra a diferença. O lado esquerdo da figura mostra o se-

32

3.2. TIPOS DE FLUXOS EXCEPCIONAIS

Figura 3.2 Fluxos candidatos à criação de casos de teste

guinte fluxo excepcional: no método d uma exceção é lançada e passa pelos métodos ce b até atingir o método a onde a exceção será capturada. Este é denominado de fluxoexcepcional real. No caso da semântica de fluxo mínimo, todos os elementos devem serparte do fluxo excepcional real, ou seja, um subconjunto deA(actual exception path), po-rém a ordem das chamadas devem obedecer a ordem de prioridade do fluxo excepcionalreal. Em A, d precede c que precede b que por sua vez precede a. Em B(valid minimalpath) temos alguns exemplos de fluxos válidos. A ordem de prioridade é obedecida maselementos podem ser omitidos.

Temos em C(invalid minimal path) alguns exemplos de fluxos inválidos. No pri-meiro exemplo d > b > c difere no que se refere a prioridade dos nós do fluxo comrelação ao original em A no qual c tem precedência em elação a b. No segundo exem-plo temos o último nó a seguido por c. Para este ser válido, a deve ser o último nó nofluxo de propagação da exceção. O mesmo ocorre no terceiro exemplo onde b está apósa. Logo, caso a ordem de precedência vier a divergir do fluxo excepcional real, este setorna inválido.

Para especificar um fluxo excepcional seguindo a abordagem proposta, um caso detestes pode ser especificado com o seu fluxo excepcional completo A ou através dasemântica de fluxo mínimo B.

33

3.3. TESTE DO COMPORTAMENTO EXCEPCIONAL

Figura 3.3 Tipos de fluxos excepcionais: Completo, Mínimo[58].

3.3 Teste do comportamento ExcepcionalTendo em vista as limitações apresentadas nas seções anteriores, propomos uma novaabordagem para lidar com o comportamento excepcional em um sistema de software.Esta abordagem possui três pontos fundamentais. São eles: especificação, monitora-mento e verificação do comportamento excepcional em um sistema de software. Naespecificação, a ideia central consiste em definir o fluxo excepcional ao qual uma deter-minada exceção deve percorrer ao longo do sistema. Após a definição de todos os fluxosexcepcionais, estes são elaborados através de testes semiautomáticos. Os casos de testeposteriormente são executados. Os resultados são comparados com o fluxo excepcio-nal definido no caso de teste através do monitoramento do comportamento excepcionalrealizado em tempo de execução.

A abordagem visa atender sistemas já existentes e sistemas novos, dando suporte aconcepção, implementação, verificação e correção de erros relativos aos comportamen-tos excepcionais em um sistema.

3.3.1 Utilizando a abordagem em aplicações existentes

Não é incomum nos depararmos no dia a dia profissional com situações em que deve-mos lidar com a manutenção de sistemas já existentes. A abordagem proposta tambémvisa dar suporte a manutenção e especificação do comportamento excepcional para taisaplicações. A Figura 3.4 ilustra as etapas desta abordagem.

34


Selecionando os fluxos excepcionais mais importantes

Para esta etapa, devemos selecionar a última versão estável do sistema com o objetivo deespecificar os fluxos excepcionais. Após a consulta aos artefatos existentes do sistema(documento de arquitetura, requisitos ou historia de usuários, código fonte ou quaisquerinformações disponíveis deste sistema), a primeira atividade consiste na seleção dosfluxos excepcionais mais importantes de acordo com as recomendações da seção 3.1.1.Estes fluxos representam situações internas ou fatores externos que tornam o sistemaimpossibilitado de prover o serviço esperado.

Criação dos casos de testes

Nesta etapa os casos de testes são criados para todos os fluxos excepcionais definidos naetapa anterior. São definidos: o local onde a exceção é lançada, os locais intermediáriospor onde a exceção percorre e o local onde esta é tratada. Em alguns casos, parte do fluxoexcepcional não está disponível (como por exemplo, chamadas a alguma biblioteca).Tendo em vista esta particularidade ou até mesmo caso não seja relevante especificá-locompletamente, é possível omitir parte deste fluxo excepcional. Conforme a necessidadeao longo da evolução do sistema, a definição deste fluxo poderá ser complementado.

Figura 3.4 Visão da abordagem proposta para sistemas existentes[58].

35


Execução dos testes

Nesta etapa, reunimos todos os casos de testes e os agrupamos de acordo com as suascaracterísticas em suítes de testes. As suítes de testes devem ser executadas e os flu-xos excepcionais ocorridos na execução dos casos de teste devem ser registrados paraposterior verificação.

Verificação dos resultados

Os fluxos excepcionais disparados pela execução de um caso de teste são utilizados paraobtenção do resultado do teste através da sua comparação com o fluxo excepcional espe-cificado. Se todos os testes passarem, consideramos que o comportamento excepcionaldo sistema adere à sua especificação. Caso contrário, inconsistências são encontradas. Omotivo da ocorrência de uma inconsistência poderá ser devido à atividades de manuten-ção ou à presença de um fluxo não previsto. Somente a segunda é considerada bug paraa nossa abordagem. Mudanças de nomes de métodos e classes, a adição de novos mé-todos na cadeia de chamada podem ocasionar divergências. Estas divergências não sãoconsideradas bugs pois são mudanças inerentes à evolução de um sistema de software.

Verificação de inconsistência e correção dos erros

Nos casos em que o teste não passou, deve-se verificar o motivo da inconsistência. Emcaso de mudança de fluxo excepcional devido à evolução do sistema, o caso de testedeverá ser atualizado e reaplicado. Nas situações em que for verificado inconsistênciadevido a comportamentos não esperados, o componente testado deverá ser corrigido e,caso haja necessidade, os testes devem ser atualizados.

Reaplicação dos testes

Após a correção dos bugs no programa, bem como a atualização dos casos de testesnecessários, os testes devem ser reexecutados e o ciclo continua da etapa 4 (Verificaçãodos resultados) até que as condições de aceitação sejam atendidas para o caso de teste.

3.3.2 Utilizando a abordagem em novos sistemas

A arquitetura de software representa explicitamente a estrutura de um sistema [42]. Esteé um dos primeiros artefatos que permite a análise de atributos de qualidade do sis-tema tais como dependabilidade, confiabilidade, disponibilidade, segurança de funcio-

36


Figura 3.5 Representação da propagação de exceções na arquitetura.

namento (safety), segurança (security)[41]. Tolerância a falhas, no nível arquitetural,tem recebido atenção considerável, principalmente no contexto do tratamento de exce-ções [13, 21, 42, 60, 61]. Brito et al. demonstram uma particular preocupação sobrepropagação de erros e tratamento de exceções no nível da arquitetura. Em nossa aborda-gem esta é a primeira etapa na qual nos concentramos na definição do comportamentoexcepcional de um sistema.

Em nossa abordagem, para a especificação do comportamento excepcional para no-vos sistemas, a primeira etapa consiste na avaliação dos requisitos, casos de uso e ce-nários excepcionais ( figura 3.6 parte 1). Após a avaliação destes artefatos os fluxosexcepcionais a nível da arquitetura devem ser levados em conta. A figura 3.5 ilustrao um exemplo de fluxo excepcional e sua cadeia de propagação em um sistema emcamadas. Nesta figura, em DataComponent.getUser, há o lançamento de uma ex-ceção do tipo verb|UserNotFoundException| que por sua vez é repassada para o métodoBusinessComponent.getUserData. Em BusinessComponent é capturadae mapeada em uma exceção do tipo UserDataNotFoundException que é propa-gada até GIUComponent.displayData.

Caso seja necessário, a abordagem permite a criação de dois diagramas que aju-dam a documentar e facilita o entendimento das exceções e os fluxos de propagaçãopercorridos por esta como pode ser observado na figura 3.6 partes 2 e 3. O primeiroartefato é o diagrama de componentes e sua interface excepcional. Na Figura 3.7 temos

37


Figura 3.6 Etapas da abordagem para novos sistemas.

um exemplo deste diagrama baseado no fluxo excepcional visto na figura 3.5. Nestediagrama os componentes do sistema são estabelecidos e as interações entre os com-ponentes são especificadas através de suas interfaces providas e requeridas. Cada in-terface deve conter os serviços e as exceções que os mesmos podem lançar. Nesteexemplo, o componente DataComponent provê o serviço getUser. Se o compo-nente, por algum motivo, não conseguir prover o serviço esperado, este deverá sinalizaruma exceção do tipo UserNotFound ao componente que requisitou o serviço. OBusinessComponent provê o serviço getUserDetail e caso não seja possívelprover este serviço, o componente GUIComponent deverá ser notificado através deuma exceção UserDetailsNotFound. Após a definição inicial dos componentes, adepender da necessidade, os módulos podem ser mais detalhados provendo a definiçãodos seus componentes internos e dos seus fluxos excepcionais. Após a definição doscomponentes e suas interfaces excepcionais o diagrama de sequência também pode sergerado.

Este diagrama também é opcional e tem por objetivo detalhar as informações sobreos fluxos excepcionais esperados nas interações entre os componentes.

Este tem por objetivo detalhar as informações sobre os fluxos excepcionais esperadosnas interações entre os componentes. Na Figura 3.8 podemos ver, de maneira maisdetalhadas as informações dos fluxos excepcionais entre os componentes.

Após a definição dos artefatos de arquitetura e projeto, a fim de dar suporte à cons-trução e verificação dos fluxos excepcionais, o caso de testes devem ser elaborados se-guindo a metodologia TDD ( figura 3.6 partes 4 a 8). Os testes devem preceder a própria

38


Figura 3.7 Diagrama de componentes

Figura 3.8 Diagrama de sequência

implementação do módulo a ser testado.No TDD o primeiro passo consiste em imaginar o comportamento que o código

deverá apresentar na etapa Pensar (figura 3.6 parte 4). Após esta atividade pensa-se emum teste pequeno que irá falhar a fim de verificar o fluxo excepcional esperado.

Na segunda etapa, barra vermelha (3.6 parte 5), o código de teste relativo ao fluxoexcepcional deve ser escrito. Após a definição inicial dos casos de testes, estes deverãoser executados. No entanto, como a cadeia de chamadas ainda não está implementada,o teste deverá falhar. Na Figura 3.9 podemos verificar uma versão inicial do nosso casode teste.

Na etapa Barra Verde (figura 3.6 parte 6) deve ser criada uma versão inicial de cadaelemento requerido no caso de teste. Para este exemplo começaremos comDataFacade

seguido por BusinessControl e GUIControler. O próximo passo consiste emescrever o código funcional (vide Figura 3.10), lembrando que, segundo os conceitos de

39


Figura 3.9 Implementação do caso de teste

TDD, devemos codificar apenas o suficiente para o teste passar. Após a codificação docódigo funcional, o teste deverá ser executado novamente. Se o teste falhar, o códigodeverá ser corrigido, e os passos reexecutados até a obtenção de um código estável.

Após o teste passar chega a hora da refatoração (figura 3.6 parte 8). Nesta etapa,examine o código identificando melhorias. Para cada ponto identificado, refatore o có-digo trabalhando em uma série de pequenas melhorias. Após cada refatoração os testesdevem ser executados novamente com o objetivo de detectar efeitos colaterais devido aesta atividade.

Antes da conclusão dessas três ultimas atividades, Barra Vermelha, Barra Verde e Re-fatorar, o ciclo de verificação (figura 3.6 partes 9 a 11) deverá ser realizado. Neste cicloa primeira atividade consiste na execução dos casos de testes seguida pela verificaçãodos resultados e caso haja necessidade, correções devem ser efetuadas.

Novos testes de fluxos excepcionais deverão ser adicionados no após o término dociclo completo do TDD.

Acreditamos que esta fase orienta o desenvolvimento dos casos de testes que lidamcom o comportamento excepcional. A utilização dos conceitos da abordagem TDD,conduz o desenvolvedor a produzir código referente ao tratamento de exceções de umaforma mais controlada.

40


Figura 3.10 Criação das classes básicas

3.3.3 Framework

Esta seção tem por objetivo apresentar a ferramenta desenvolvida com o objetivo dedar suporte a abordagem proposta. Para isto, foi desenvolvida uma extensão do JUnitframework chamada JUnitE.

O JUnitE permite a definição de fluxos excepcionais esperados em termos do localonde a exceção é lançada, os locais intermediários onde passam antes de atingir o seutratador e o local onde a exceção é tratada. Também permite a verificação em tempode excecução os resultados obtidos nos testes do comportamento excepcional de umaaplicação. A extensão também permite a verificação de transformações de exceçõesmesmo que não haja o encapsulamento da exceção original na nova exceção.

A figura 3.11 mostra a estrutura do JUnitE. A classe principal é a JunitETestCasenesta, estão concentradas as adaptações para fornecer meios para a verificação dos tes-tes excepcionais. Para a criação de um teste excepcional o caso de teste deve estenderdiretamente de JunitETestCase. O aspecto ExceptionLogAspect é responsável por moni-

41


Figura 3.11 Visão jUnite tool

torar e a classe FileWriterUtil de salvar o log de execução dos fluxos excepcionais para aposterior verificação. As anotações @PartialSequencialMode e @FullSequencialModeindicam o tipo de verificação desejada no teste excepcional seguindo o modelo da seção3.3.1 onde @PartialSequencialMode indica a possibilidade de omissão de elementos dofluxo excepcional e @FullSequencialMode indica que tanto o fluxo excepcional definidoquanto o obtido pela execução caso de testes devem ser iguais contrário, o teste deveráfalha. Caso um caso de teste não seja anotado por nenhuma destas duas, o modo deverificação parcial é utilizado por padrão. As anotações @ForceException e @Force-ExceptionOnContructor indicam que um teste excepcional deve forcar o lançamento deuma exceção e devem ser usadas em conjunto com a anotação @Test do JUnit. Atravésdo pré-processamento na classe AspectGenerator estas anotações são utilizadas para a

42


geração de aspectos que forçam o lançamento de uma exceção de acordo com os parâ-metros fornecidos.

A Figura 3.12 podemos observar um exemplo de teste excepcional escrito para oJUnitE. Neste exemplo, a definição do fluxo excepcional esperado é definido como umarray de string (linhas 13-18) que segue algumas convenções para indicar o tipo deexceção (linha 14), o local onde a exceção é levantada (linha 15), locais intermediáriospor onde a exceção é propagada (linha 16) e o local onde é tratada (linha 17). A or-dem dos elementos nesta matriz indica a ordenação deste fluxo, desde o local onde aexceção é levantada, até o local do tratamento desta exceção. Os métodos exception,raiseSite, intermediateSite e handlingSite fazem parte da sintaxe paraa definição do fluxo excepcional. O método exception indica o tipo da exceção es-perada, raiseSite indica o local onde a exceção é lançada, intermediateSiteé utilizado para indicar os locais intermediários e handlingSite para indicar o localonde a exceção é capturada. Após definido o fluxo excepcional, o array definido deveser passado como parâmetro ao método setExceptionPath(String[]) antes daexecução do caso de teste.

O método testEHFlowDAOServlet (linha 10) implementa o caso de teste uti-lizando a anotação @Test do JUnit (linha 9). Como em qualquer abordagem de testefuncional, o teste é responsável por desencadear a condição de erro que resultará na exce-ção esperada, no nosso exemplo a chamada ao método myServlet.service (linha25).

Em alguns casos torna-se necessário redefinir o comportamento do resultado de umteste. Por exemplo, podemos ter uma determinada situação em que o testador descobreum erro devido à ocorrência de uma exceção não tratada que ocasiona a interrupção deforma não esperada da execução do sistema. Neste caso ele poderá especificar o fluxoexcepcional indesejado para que, ao longo da evolução do sistema, seja possível verificarse este fluxo inesperado ainda ocorre. Para isso deve-se especificar um teste com o fluxoexcepcional não esperado e o método result deverá ser redefinido da seguinte forma:

//Método da superclasse, o override é opcional.

//Use para modificar o resultado do teste.

public void result() {//Ex: se uma exceção especificada ocorrer,

//o teste não deverá passar

assertTrue(!verifyResults());}

Desta forma o teste somente irá passar se a exceção especificada não ocorrer durante

43


1 - public class MyTestCase extends JuntETestCase {2-3- //This annotation forces an exception4- //to be trigged5 - @ForceException(exception="java.io.IOException",6 - method = "MyDAO.insertData",7 - methodReturnType = "void",8 - methodParType = "java.lang.String")9 - @Test10- public void testEHFlowDAOServlet() {11-12- //Specifies the desired exception path13- String[] trace = new String[]{14- exception("java.io.IOException"),15- raiseSite("MyDAO.insertData "),16- intermediateSite("myFacade.insertData"),17- handlingSite("myServlet.service")18- };19-20- //Sets the exception path21- super.setExceptionPath(trace);22-23- //Calls the element that should handle24- //the exception25- myServlet.service();26- }27-}

Figura 3.12 Exemplo de caso de teste

a execução de um caso de teste.O JUnitE também permite a geração de um arquivo de log após a execução de testes.

Abaixo temos um exemplo ilustrativo do arquivo gerado:

1 - #pkg.MyException2 - pkg.raisingSite

3 - pkg.intermediateSite1

4 - pkg.intermediateSite25 - @pkg.catchingSite

Neste arquivo, o símbolo # representa o tipo de exceção (linha 1), na linha subse-quente (linha 2) temos o local onde a exceção foi levantada, neste casopkg.raisingSite. Sempre a linha após a exceção define o local onde a exceção

44


foi levantada. Nas linhas 3 e 4 temos a definição dos locais intermediários por ondea exceção trafega. Por fim, temos na linha 5 o local onde a exceção é tratada definidapelo símbolo @. Caso este símbolo não apareça em um fluxo excepcional significa quea exceção não foi capturada ocasionando o término da execução do caso de teste. Emum mesmo arquivo de log podemos ter vários blocos similares ao exemplo. Isto indicaa presença de múltiplos fluxos excepcionais durante a execução do teste. Este arquivocontém todas as informações do fluxo de exceção produzido pela execução do caso deteste. Esta informação é importante pois com ela é possível acompanhar as mudançasentre as versões de um sistema.

Figura 3.13 Resultado de um caso de teste.

Porém a verificação manual do log é opcional para a abordagem proposta. Para umteste passar não é necessária avaliação manual deste arquivo. Está avaliação é realizadaautomaticamente pelo JUnitE e a apresentação do resultado do teste é similar ao JUnito qual representa um teste que passou através de uma barra verde e barra vermelha paratestes que falharam. Na figura 3.13 podemos observar o resultado de um teste no JUnitE.

Uma falha ocorre quando o fluxo excepcional, que é registrado no log de execução,não for igual ao fluxo excepcional especificado. Esta verificação é realizada automatica-mente comparando-os durante a execução do caso de teste.

O JUnitE também permite a criação de casos de teste que verifiquem o remapea-mento de exceções de um tipo para outro como no exemplo da Figura 3.14. Esta figuramostra a execução dos métodos a, b e c nesta ordem. O método c lança uma exceção

45


Figura 3.14 Transformação de tipo uma exceção.

do tipo IOException e a propaga até o método b. O método b captura essa exceçãoe a remapeia em uma exceção do tipo MyException que é posteriormente capturadapelo método a. Infelizmente o JUnit não suporta este tipo de definição.

3.3.4 Monitorando exceções

Para a monitoração da propagação das exceções durante a execução dos casos de testes,foi utilizada programação orientada a aspectos [28]. O módulo de monitoração capturatodas as informações necessárias como: tipo de exceção lançada, os métodos percorri-dos, o método que a capturou e se a exceção foi tratada ou re-mapeada. O trecho decódigo abaixo demostra a captura do objeto que encapsula a exceção ocorrida:

1- pointcut callexecutionGeneral(): handler(Throwable+)

&& !within(br.cin.ufpe.exflow.*) //Exclui os pacotes da ferramenta.&& !within(br.cin.ufpe.exflow.injection.tool.*)

&& !within(br.cin.ufpe.exflow.injection.*);

2- handler(Throwable+) ;3- before(Throwable e) :

4- callexecutionGeneral() && args(e) {5- //Antes do tratamento de uma

6- //exceção do tipo Throwable

7- //ou qualquer subtipo, os8- //objetos que representam a exceção

9- //são capturados e repassados para o JUnitE

10- }

Através deste objeto e com as informações do local onde o advice (vide Seção 2.7)afetou o código da aplicação testada, é possível definir o fluxo percorrido por uma exce-ção.

46


Porém há situações em que uma exceção é lançada, mas não há nenhum tratadorque capture esta exceção. Desta forma o código anterior não detectaria a ocorrência deuma exceção. Imagine que devido a um erro de programação um objeto que deveria seratribuído a um atributo de uma classe, por algum motivo, não é inicializado. Em algummomento este atributo é acessado, mas no momento da sua leitura, sua referencia estánula. Esta exceção é propagada com o objetivo de tentar achar um tratador adequado aoseu tipo. Se nenhum tratador for compatível com este tipo, o programa irá abortar a suaexecução. Para casos como este temos o seguinte trecho de código:

1- pointcut callexecutionGeneralUnhandled(): call(* *.*(..))

&& !within(br.cin.ufpe.exflow.*) //Exclui os pacotes da ferramenta.

&& !within(br.cin.ufpe.exflow.injection.tool.*)&& !within(br.cin.ufpe.exflow.injection.*);

2- call(* *.*(..));

3- after() throwing(Throwable e) :4- callexecutionGeneralUnhandled() {

5- //A cada lançamento de uma exceção,6- //este advice envia o nome do método

7- //e da exceção para o JUnitE

8- }

Neste trecho de código, na chamada a qualquer método da aplicação(call(* *.*(..))) que levantar ou propagar uma exceção(after() throwing(Throwable e) : ...), o advice guarda as chamadas,na ordem que estas são executados e as repassam para o JUnitE. Estas duas construçõessão usadas para verificar a aderência do fluxo excepcional especificado em comparaçãoao fluxo obtido através da execução do teste. Se não houver divergência entre o estesdois o teste falha.

Uma limitação do framework é observada devido às características do jUnit o qualfalha um teste caso uma exceção seja propaganda até o método de teste caso não forusada a anotação @Test(expected=Ex). Devido a esta característica, em algunstestes elaborados para a avaliação da abordagem, utilizamos blocos try-catch dentrodo método de teste pois há situações nas quais desejamos verificar se o fluxo excepci-onal encerra no método de teste (vide exemplo no apêndice A.1.33 ). Caso a anotação@Test(expected=Ex) seja usada, irá suprimir o resultado do jUnitE desconside-rando a verificação do fluxo excepcional.

47

3.4. COMO MONTAR O AMBIENTE DE TESTES

3.3.5 Forçando exceções

Em algumas situações torna-se difícil a reprodução das condições que provocam o dis-paro de uma exceção. Podemos observar facilmente esta necessidade quando tentamosreproduzir uma exceção derivada de fatores externos como erros de I/O. Neste caso de-finimos um caso de testes que contenha uma chamada que deverá exercitar a exceçãopretendida. Devido a dificuldade de obter esta exceção de forma natural, devemos forçaro seu lançamento. O JUnitE permite forçar o lançamento de uma exceção sem a ne-cessidade de modificação no código original da aplicação. Para isso devemos utilizar aanotação @ForceException no método de teste. Na Figura 3.12 (linhas 5-8) temosum exemplo desta construção. Neste exemplo, através da anotação ForceException,é possível lançar uma exceção do tipo java.io.IOException quando o métodoMyDAO.insertData(String) for executado.

Para que a funcionalidade de forçar uma exceção funcione, foi desenvolvido umpré-processador que verifica todas as anotações ForceException de um caso deteste e geram automaticamente um aspecto sem a necessidade do programador possuirconhecimento de AOP. Os desenvolvedores necessitam somente fazer weaving [28] eentão o aspecto irá forçar o lançamento de uma exceção.

O trecho de código a seguir mostra o exemplo de um aspecto (vide Seção 2.7) geradopelo pré-processador:

1- public aspect MyTC {

2- pointcut tc():

3- execution(void MyDAO.insertData(String));4-

5- void around() throws

6- java.io.IOException :tc() {7- throw new java.io.IOException();

8- }

9- }

Este aspecto substitui a implementação de MyDAO.insertData(String) pelolançamento da exceção do tipo java.io.IOException (linha 7).

3.4 Como montar o ambiente de testesEsta seção tem por objetivo guiar de forma prática como configurar um ambiente parateste do comportamento excepcional de uma aplicação utilizando o JUnitE. Para este

48


exemplo estamos utilizando o Eclipse2 como ambiente de desenvolvimento. O JUnitEé uma extensão do JUnit versão 4.0, logo, deve-se adicionar ao classpath do projetoo JUnit 4. Devido ao módulo de forçar exceções assim como o de monitoramento deexceções utilizarem programação orientada a aspectos implementada através do AspectJ,é necessário a integração com o AJDT (AspectJ Development Tools)3.

Figura 3.15 Criação de um projeto Aspectj.

O primeiro passo consiste na criação de um projeto Aspectj (Figura 3.15). Logoapós, deve-se adicionar a biblioteca do JUnit no classpath do projeto através dos coman-dos: Project > Properties > Java Build Path > Libraries > Add Library ... > JUnit >Selecione JUnit 4 (Figura 3.16)

O passo seguinte consiste em criar uma pasta chamada "lib". Dentro desta pastadeve-se copiar a o .jar do JUnitE4. Após a cópia, o JUnitE deve ser adicionado ao classpath do projeto (Project > Properties > Java Build Path > Libraries > Add Jars , Figura3.17).

Para que a monitoração das exceções ocorra é necessário copiar o arquivo Excepti-onLogAspect.aj e adicioná-lo à pasta "src"do projeto. No nosso exemplo adicionamos

2www.eclipse.org3www.eclipse.org/ajdt4 Disponível em: sites.google.com/site/junitecomousar/junite

49


Figura 3.16 Adicionando o JUnit ao projeto.

no pacote br.cin.ufpe.br.junite.moritoring.Após estes passos o ambiente já está pronto para uso. Em jEditeSample.zip5 temos

um exemplo simples e a estrutura básica de um projeto usando o JUnitE.

Figura 3.17 Adicionando lib do JUnitE.

5Disponível em: sites.google.com/site/junitecomousar/junite

50

4Avaliação

Neste capítulo são apresentados os resultados obtidos através do uso da abordagem pro-postas. Parte desta avaliação foi descrita nos artigos: "Towards Agile Testing of Excep-tional Behavior"[59] e "Agile Testing of Exceptional Behavior"[58].

Para esta avaliação escolhemos verificar inicialmente um dos possíveis usos da abor-dagem proposta. Nesta ocasião foram concentrados os esforços na aplicação da aborda-gem em sistemas existentes (seção 3.3.1). Acreditamos que este é um cenário potencialde uso da abordagem proposta e de bastante importância no apoio à manutenção de siste-mas. Um fato que foi preponderante para esta escolha foi a indisponibilidade de recursospara apoiar a elaboração de um estudo controlado com o objetivo de avaliar a abordagempara sistemas novos.

Devido ao escopo deste trabalho, para esta avaliação estamos interessados em desco-brir apenas bugs relacionados ao mau uso do mecanismo de tratamento de exceção. Ou-tros tipos de bugs são desconsiderados para este estudo. Para esta avaliação, a primeiraatividade foi a escolha dos sistemas alvo. Estes foram selecionados por terem atendido auma série de critérios relevantes para a nossa avaliação. Primeiro, estes são projetos desoftware não-triviais. Em particular, dois deles são aplicações de produção de qualidadeutilizados por milhares de usuários.Para a escolha destes dois sistemas foi realizada umabusca no Sourceforge1. O primeiro critério de filtro foi a linguagem de programação.Os sistemas deveriam de código livre e desenvolvidos em Java devido a compatibilidadecom o jUnitE e AspectJ. Devido a características da avaliação, o sistema deveria tervárias versões disponíveis. Algumas aplicações candidatas apresentavam este requisitoporém ao obter o código fonte, estes não compilavam. Os sistemas que apresentavameste problema foram desconsiderados. Um outro critério levado em conta na escolhados sistema a quantidade de código dedicado ao tratamento de exceções. O ultimo crité-

1www.sourceforge.net

51

rio é relativo a função do tratamento de exceção. Nos sistemas avaliados, o função dostratadores de exceção variaram significativamente em termos de sua finalidade (ex: log-ging, transação de recuperação específica da aplicação, etc). Posteriormente um terceirosistema foi selecionado. Este é um sistema de referência utilizado por outros estudos[4, 19, 49, 71, 79].

Após escolhidos os sistemas, a primeira versão estável de cada um foi selecionada eseu comportamento excepcional especificado. Os testes criados para esta versão foramreaplicados para as versões posteriores. Os casos de testes nos quais alguns elementosfluxo excepcional especificado sofreram mudanças (de nomes de classes / métodos, ele-mentos removidos, etc.), foram atualizados com o objetivo de manter a sua consistência.Tais mudanças não são consideradas bugs, pois se trata da evolução natural do software.

Inicialmente selecionamos dois sistemas opensource: o aTunes e o jEdit. Posterior-mente selecionamos mais um sistema, o Health Watcher. Este foi escolhido para avaliaro impacto e a eficácia desta extensão em um sistema orientado a aspectos tendo em vistaque o JUnitE utiliza AOP em parte de sua construção.

Para os sistemas aTunes e jEdit, algumas versões intermediárias não foram testadasdevido a pequenas mudanças entre versões no que se refere ao código de tratamento deexceções. A Tabela 4.2 resume o resultado de teste para o aTunes, a Tabela 4.5 para ojEdit e a Tabela 4.7 mostra os resultados para o Health Watcher.

Na avaliação realizada, a maioria dos casos de teste apresentam um teste (atravésda anotação @test) por classe. Porém é possível associar mais de um teste por casode teste como pode ser observado no TC04 do aTunes (vide apêndice A.1.4). Tambémé possível adicionar mais de um fluxo excepcional a um método anotado por @testcomo pode ser observado no teste TC12 ao aTunes (vide apêndice A.1.12).

Para a nossa abordagem um caso de teste pode passar ou apresentar alguma divergên-cia. Divergências podem ser de dois tipos: falha, representando um fluxo excepcionalindevido ou evolução, representando mudanças de nomes de métodos/pacotes ou adi-ção de caminhos intermediários de propagação dentro de um fluxo excepcional. Estasegunda não é caracterizada falha em um caso de teste. Nas tabelas que apresentamos resultados, testes marcados como Passou indicam que passam sem restrições. Já ostestes marcados por PASSOU-Upd (passou mas necessita de atualização) indicam quepassaram mas houve algum tipo de divergência no fluxo excepcional. Porém tais di-vergências ocorreram devido à mudanças de nomes de métodos ou pacotes. Para estasituação, os casos de testes devem ser atualizados com o objetivo de refletirem o fluxoexcepcional mais atual. Os testes sinalizados por FALHOU indicam que os testes não

52

4.1. AVALIAÇÃO DO SISTEMA ATUNES

atenderam os requisitos relacionados ao fluxo excepcional do caso de teste. Testes mar-cados por NA indicam a sua indisponibilidade para uma determinada versão do sistemadevido à remoção do fluxo excepcional antes existente.

4.1 Avaliação do sistema aTunes

O primeiro sistema avaliado foi o aTunes2. O aTunes é um reprodutor de música queagrega muitas funcionalidades. Atualmente suporta os arquivos de mídia mp3, ogg,wma, wav, flac, mp4 e streaming de rádio. Algumas funcionalidades presentes nestesistema são: editação de tags, organização das músicas e extração de faixas de áudio, etc.Esta aplicação possui entre 18.513 (na versão inicial) e 49.994 (última versão avaliadaneste estudo). Apesar de seu tamanho relativamente pequeno, aTunes tem uma grandebase de usuários (cerca de 4.800 downloads semanais no sourceforge.net). A tabela 4.1apresenta algumas estatísticas relevantes sobre as versões analisadas de aTunes.

Versão/ aTunes 1.5 aTunes 1.6 aTunes 1.9 aTunes 1.10 aTunes 1.11 aTunes 1.12 aTunes 1.13MétricaLOC 18513 19167 38948 42353 44702 46085 49994LOC TE 531 546 1472 1616 1659 1769 2028% LOC TE 2,87% 2,85% 3,78% 3,82% 3,71% 3,84% 4,06%classes 195 215 363 419 505 513 548blocos try 124 124 269 291 298 315 362blocos catch 135 136 311 344 348 374 432instr. throw 0 0 35 39 42 45 49

Tabela 4.1 Métricas do sistema aTunes.

O primeiro passo para a avaliação do aTunes foi a escolha da versão base. Come-çamos com a versão 1.5 baseado na estabilidade do código (houve grandes mudançasentre 1.3 e 1.4). Após a escolha da versão base, especificamos os fluxos excepcionaisesperados. Os casos de testes especificados para a versão 1.5 serviram como base paraas outras versões. Devido às alterações de código entre versões, alguns casos de testetiveram de ser redefinidos e novos foram criados. Essas mudanças foram desencadeadaspor alterações na implementação do comportamento excepcional ou mudanças em no-mes de pacote e métodos. Em alguns casos métodos públicos e algumas classes foramremovidos. Nesta situação os casos de teste foram redefinidos ou até mesmo removidos.

As versões 1.5, 1.6, 1.9, 1.10, 1.12, e 1.13 do aTunes foram testadas através de 17casos de teste. Foram observados 4 bugs durante a execução dos testes nas 6 versõesanalisadas como pode ser observado na Tabela 4.2. A tabela Table 4.3 fornece uma

2http://www.atunes.org/

53

4.1. AVALIAÇÃO DO SISTEMA ATUNES

Test case aTunes1.5 aTunes 1.6 aTunes 1.9 aTunes 1.10 aTunes 1.12 aTunes 1.13TC01 Passou Passou Passou-Upd FALHOU FALHOU FALHOUTC02 Passou Passou Passou Passou Passou Passou-UpdTC03 Passou Passou Passou-Upd Passou Passou Passou-UpdTC04 Passou Passou Passou-Upd Passou Passou PassouTC05 Passou Passou-Upd NA NA NA NATC06 Passou Passou-Upd NA NA NA NATC07 Passou Passou Passou-Upd Passou Passou Passou-UpdTC08 Passou Passou-Upd NA NA NA NATC09 Passou Passou NA NA NA NATC10 Passou Passou Passou FALHOU FALHOU FALHOUTC11 Passou Passou FALHOU Passou. Passou. PassouTC12 Passou Passou Passou Passou Passou PassouTC13 NA NA Passou Passou-Upd NA NATC14 Passou Passou Passou-Upd Passou Passou Passou-UpdTC15 NA NA Passou Passou-Upd NA NATC16 NA NA Passou Passou Passou-Upd PassouTC17 NA NA FALHOU FALHOU FALHOU FALHOU

Tabela 4.2 Resultado dos testes para as versões analisadas do aTunes.

breve descrição de cada falha encontrada durante a execução do conjunto de teste. Emseguida vamos aos detalhes de alguns deles.

Caso de teste Falha de sinalização Falha de tratamentoTC01 Exceção esperada: TransactionExceptionVersões: - Exceção forçada: RuntimeException1.10 to 1.13 Tratador esperado: Program main

Tratador atual:AudioScrobblerService.getSimilarArtists

TC10 Exceção esperada: TransactionExceptionVersões: - Exceção forçada: RuntimeException1.10 to 1.13 Tratador esperado: Program main

Tratador atual:AudioScrobblerService.getSimilarArtists

TC11 Exceção esperada: FileNotFoundExceptionVersões: Exceção atual: NullPointerException -1.9TC17 Exceção esperada: nenhumaVersões: Exceção atual: NullPointerException -1.9 to 1.13

Tabela 4.3 Falhas encontradas no sistema aTunes .

Na versão 1.9 do aTunes encontramos o primeiro bug. No caso de teste TC113 ,que deveria lançar uma exceção do tipo java.io.IOException como podemos verabaixo:

Raise site: java.io.IOException

Intermediate site: net.sourceforge.atunes.kernel.utils.

PictureExporter.savePictureCatch site: net.sourceforge.atunes.kernel.handlers.

RipperHandler.savePicture

3Código disponível no apêndice

54

4.2. AVALIAÇÃO DO SISTEMA JEDIT

Porém uma exceção do tipo java.lang.NullPointerException é lan-çada. No trecho abaixo podemos ver o log de execução do caso de teste executado:

#java.lang.NullPointerException

net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.savePictureToFile

net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.

[email protected]

Neste caso de teste uma exceção do tipojava.lang.NullPointerExceptioné lançada e repassada até o método de teste do caso de teste. Após avaliar o código fontea fim de verificar a causa fonte deste bug, foi observado que o métodoAudioFilePictureUtils.savePictureToFile (figura 4.1) sempre retornauma referência nula. Isto ocorre devido à remoção de parte da lógica de negócio ocasio-nando o retorno de uma referência nula. Este objeto é acessado gerandoNullPointerException. Devido à exceção não ser tratada, a aplicação é encer-rada de maneira não esperada. O trecho de código da figura 4.1 demonstra o pro-blema. Neste, o método savePictureToFile (linha 1) faz chamada ao métodogetInsidePicture (linha 8) que retorna null (linha 13). A referência nula é atri-buida a image (linha 3) e depois o método getImage é chamado (linha 5) causandoa exceção.

Na versão 1.10, encontramos nos casos de testes TC01 e TC10 uma situação ondeum tratador genérico java.lang.Exception foi deixado no código fonte porém, ocódigo o qual era passível de levantar uma exceção foi removido. Problemas como estesão uma fonte potencial de bugs [55]. Inspecionando a base de bugs aTunes 4, observa-mos que nenhum desses problemas tinham sido relatados anteriormente. Encontramosdois bugs em versões posteriores que haviam sido relatados. Desde a versão 1.9 até 1.13,o caso de teste TC17 revelou uma exceção não tratada.

4.2 Avaliação do sistema jEditDecidimos avaliar um segundo sistema, maior e com mais código relacionado ao trata-mento de exceções. Para esta ocasião foi selecionado o jEdit 5. Este permitiu que aabordagem fosse aplicada em um contexto maior e mais complexo. O jEdit é um editor

4http://sourceforge.net/tracker/?atid=821812&group_id=1619295http://www.jedit.org/

55


1 private static void savePictureToFile() throws ... {23 ImageIcon image = getInsidePicture(song);45 PictureExporter.savePicture(image.getImage(),6 file.getAbsolutePath());7 }8 private static ImageIcon getInsidePicture (AudioFile file) {910 FileInputStream stream = null;1112 try {13 return null;14 } catch (Exception e) {15 return null;16 } finally {17 ClosingUtils.close(stream);18 }19 }

Figura 4.1 Método savePictureToFile()

de texto desenvolvido na linguagem Java voltado para programadores. Pode ser confi-gurado como uma IDE bastante poderosa por meio do uso de sua arquitetura plug-in.A última versão avaliada possui 97.581 linhas de código. Para esta avaliação, ao todoforam criados quinze casos de testes, oito bugs foram descobertos em cinco versõesavaliadas (4.0, 4.1, 4.2, 4.3 e 4.3.1). Inicialmente criamos os testes para a versão 4.0do jEdit. Dos quinze casos de testes especificados, dois foram elaborados baseados embugs previamente reportados 6 com o objetivo de verificar se a abordagem proposta seriaeficaz em detectar estes erros.

A tabela 4.4 apresenta estatísticas das versões analisadas do jEdit. Podemos observarna tabela 4.6 uma breve descrição de cada falha encontrada durante a realização dostestes para o jEdit. Em seguida, será detalhadas algumas destas falhas.

O primeiro bug foi encontrado na versão inicial através do caso de teste TC02. Estefoi causado pelo lançamento de uma exceção do tipo NullPointerException. Ocaso de teste foi elaborado com base em um bug previamente reportado. Como espe-rado, o JUnitE foi capaz de detectar este comportamento indevido. Após a execuçãodeste caso de teste, a sua especificação foi atualizada com o objetivo de especificar o

6http://sourceforge.net/tracker/?group_id=588&atid=100588

56


Versão/ jEdit 4.1 jEdit 4.2 jEdit 4.3 jEdit 4.32MétricaLOC 44485 55850 97498 97581LOC TE 1754 2284 5234 5253%LOC TE 3,94% 4,09% 5,37% 5,38%classes 195 224 483 483blocos try 257 328 704 704blocos catch 214 288 661 662instr. throw 99 105 548 548

Tabela 4.4 Métricas do jEdit.

Test case jEdit4.0 jEdit4.1 jEdit4.2 jEdit4.3 jEdit4.3.2TC01 Passou Passou Passou Passou Passou-UpdTC02 FALHOU FALHOU FALHOU FALHOU FALHOUTC03 Passou Passou Passou NA NATC04 FALHOU FALHOU NA NA NATC05 Passou Passou FALHOU Passou-Upd Passou-UpdTC06 Passou Passou NA Passou PassouTC07 FALHOU FALHOU NA NA NATC08 Passou-Upd Passou Passou Passou PassouTC09 Passou Passou Passou NA NATC10 Passou Passou Passou Passou PassouTC11 Passou Passou Passou-Upd Passou PassouTC12 Passou Passou Passou Passou PassouTC13 Passou Passou Passou Passou-Upd PassouTC14 Passou Passou-Upd FALHOU FALHOU FALHOUTC15 Passou Passou FALHOU FALHOU FALHOU

Tabela 4.5 Resultado dos testes para as versões analisadas do jEdit.

fluxo excepcional ocorrido. O método result do caso de teste foi redefinido(assertTrue(!verifyResults()). com o objetivo de verificar se o fluxo nãodesejado estaria presente nas versões posteriores.

Verificamos o segundo bug ainda na versão 4.0 (caso de teste TC04) devido a pro-pagação de ArrayIndexOutOfBoundsException. Similar a primeira, ambos osbugs foram ocasionados por erro de programação e já eram conhecidos através da basede bugs reportados. Novamente o JUnitE foi capaz de detectar o problema relacionadoao fluxo indevido de exceções no contexto do caso de teste. Este erro foi observado atéa versão 4.1. Após esta versão, o código relativo a esta funcionalidade foi removido.

O terceiro bug foi encontrado também na versão inicial através do caso de testeTC07. Neste, uma exceção do tipo EvalError era esperada, porém uma exceção dotipo ClassCastException foi levantada como pode ser visto no log de execuçãoabaixo:

#java.lang.ClassCastException

57


Caso de teste Falha de sinalização Falha de tratamentoTC02 : Exceção esperada: nenhumaVersões: Exceção atual: NullPointerException -todasTC04 Exceção esperada: nenhumaVersões: Exceção atual: NullPointerException4.0, 4.1TC05 Exceção esperada: bsh.EvalErrorVersões: Exceção atual: bsh.ParseException -4.2TC07 Exceção esperada: nenhumaVersões: Exceção atual: ClassCastException -4.0, 4.1TC14 Exceção esperada: java.io.IOExceptionVersões: Exceção atual: ClassCastException -4.2, 4.34.32TC15 Expected exception: NumberFormatExceptionVersões: Exceção atual: ClassNotFoundException -4.2, 4.34.32

Tabela 4.6 Falhas encontradas no sistema jEdit.

bsh.BSHArrayInitializer.eval@br.cin.ufpe.junite.jedit.test.TC07.TC07

Podemos observar que a exceção foi lançada no métodobsh.BSHArrayInitializer.eval e repassada para o método de teste. Na verifi-cação manual detectamos cast indevido da classe bsh.Node para bsh.SimpleNodeO quarto bug foi achado na versão 4.2 do jEdit no caso de teste TC05. Temos neste casode teste a seguinte especificação:

1-String [] trace = new String [] {2- exception("bsh.EvalError"),

3- raiseSite("bsh.Name.toClass"),

4- intermediateSite("bsh.BSHAmbiguousName.toClass"),5- intermediateSite("bsh.BSHType.getType"),

6- intermediateSite("bsh.BSHTypedVariableDeclaration.eval"),

7- intermediateSite("bsh.Interpreter.eval"),8- intermediateSite ("bsh.Interpreter.source"),

9- catchSite ("bsh.Interpreter.main")};

10-}

Nesta especificação, uma exceção do tipo bsh.EvalError deve ser lançada embsh.Name.toClass sendo propagada até o método bsh.Interpreter.main.Porém na execução do caso de teste, uma exceção do tipo bsh.TargetError foilançada. Podemos verificar no log abaixo o fluxo percorrido pela exceção:

58

4.3. HEALTH WATCHER

#Bsh.TargetError

bsh.Interpreter.eval

[email protected]

O quinto bug foi encontrado na versão 4.2 do sistema no caso de teste TC10. Aexceção resultante da execução do teste foi ClassCastException. Este erro ocor-reu devido a conversão indevida de tipos. Observamos o mesmo comportamento até aversão 4.3.2 deste sistema.

O sexto bug encontrado no TC11 ainda na versão 4.2 (estendendo-se até a última ver-são avaliada) refere-se ao tipo de exceção levantada. Uma exceção do tipo EvalErroré esperada (linha 2) como podemos observar abaixo:

1- String [] trace = new String []{

2- exception(bsh.EvalError "),

3- raiseSite (bsh.Interpreter.eval"),4- catchSite (test.TC11.startup ")

5- };

Porém a exceção do tipo TargetError (linha 6) foi lançada durante a execuçãodos testes. Nas linhas abaixo podemos observar o log de execução deste caso de teste.

6- #bsh.TargetError

7- bsh.Interpreter.eval

8- test.TC11.startup

Os dois últimos bugs foram encontrados na versão 4.2 nos casos de teste TC14 e TC15.Ambos os testes terminaram sua execução com o lançamento de uma exceção do tipoClassCastException. Estes erros foram observados, em ambos os casos, até aversão 4.3.2 do jEdit.

4.3 Health WatcherO terceiro sistema avaliado foi o Health Watcher (HW) [72]. O HW é um sistema Webque registra queixas e informa sobre o sistema público de saúde. Suas principais funçõessão: o registro e encaminhamento de queixas para o sistema de saúde e o fornecimentoà população de informações sobre unidades de saúde e suas especialidades. Esse sis-tema disponibiliza uma interface Web para o registro de reclamações e para consulta deinformações de interesse da população que são fornecidas pela Secretaria de Saúde.

59

4.3. HEALTH WATCHER

O HW possui uma arquitetura em camadas que separa as camadas de dados, negó-cios, comunicação e apresentação. Existem 10 versões do HW disponível tanto em Javaquanto em AspectJ. Ao contrário dos outros sistemas avaliados implementados em Java,foram selecionadas as 10 versões orientadas a aspectos do HW para esta avaliação. Arazão pela qual foi utilizado um sistema orientado a aspectos é devido a necessidade deavaliar se os aspectos gerados pelo JUnitE entrariam em conflito ou não com os aspectosjá existentes no HW. Ao total foram planejados 16 casos de teste e descobertos 6 bugsnas em 8 versões do HW. Além disso, nenhum conflito foi detectado entre os aspectosimplementados em HW e os gerados pelo JUnitE. A Tabela 4.7 apresenta o resumo dosresultados obtidos.

Versão/ HW 1.0 HW 2.0 HW 3.0 HW 4.0 HW 5.0 HW 6.0 HW 7.0 HW 8.0 HW 9.0 HW 10.0MétricaLOC 5716 6120 6722 6811 6811 6860 6885 6894 7859 7798LOC TE 1173 1280 1285 1291 1291 1291 1291 1291 1562 1395%LOC TE 20,52% 20,92% 19,12% 18,95% 18,95% 18,82% 18,75% 18,73% 19,88% 17,89%blocos try 122 140 141 142 142 142 142 142 176 152blocos catch 184 205 206 207 207 207 207 207 268 240instr. throw 175 184 185 185 185 185 185 185 229 232classes 90 98 110 110 110 113 117 117 129 133aspectos 11 14 18 21 21 22 22 24 24 25

Tabela 4.7 Métricas do Health Watcher.

HW1.0 HW2.0 HW3.0 HW4.0 HW5.0 HW6.0 HW 7.0 HW8.0 HW9.0 HW10.0TC01 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC02 FALHOU Passou-Upd Passou Passou Passou Passou Passou Passou Passou PassouTC03 FALHOU Passou Passou Passou Passou Passou Passou Passou Passou PassouTC04 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC05 FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOUTC06 FALHOU Passou Passou Passou Passou Passou Passou Passou Passou PassouTC07 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC08 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC09 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC10 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC11 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC12 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC13 Passou Passou Passou Passou Passou Passou Passou Passou Passou PassouTC14 FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOU FALHOUTC15 FALHOU Passou Passou Passou Passou Passou Passou Passou Passou PassouTC16 Passou Passou Passou Passou Passou Passou Passou Passou Passou Passou

Tabela 4.8 Resultado dos testes para as versões analisadas do HW.

A tabela 4.8 apresenta os resultados para os casos de testes e a tabela 4.9 apre-senta as falhas encontradas para este sistema. O primeiro bug foi observado na versão1AO. No caso de teste TC02 a execução do teste encerrou com uma exceção do tipoNullPointerException. Este erro ocorreu devido à tentativa de acesso ao métodode um objeto com referência nula:

60

4.3. HEALTH WATCHER

Caso de teste Falha de sinalização Falha de tratamentoTC02 Exceção esperada: TransactionExceptionVersão: Exceção atual: NullPointerExceptio -1.0 Remapeada para: PersistenceMechanismExceptionTC03 Exceção esperada: ObjectNotFoundExceptionVersão: Exceção atual: NullPointerExceptio -1.0 Remapeada para: PersistenceMechanismExceptionTC05 Exceção esperada:ConnectExceptionVersões: Exceção atual: StubNotFoundException -todasTC06 Exceção esperada: ObjectNotFoundExceptionVersão: Exceção atual: NullPointerExceptio -1.0 Remapeada para: PersistenceMechanismExceptionTC14 Exceção esperada: PersistenceMechanismExceptionVersões: Exceção atual: RuntimeException -todas Remapeada para: PersistenceMechanismExceptionTC15 Exceção esperada: ObjectNotFoundExceptionVersão Exceção atual: RuntimeException -1.0 Remapeada para: PersistenceMechanismException

Tabela 4.9 Detalhamento das falhas encontradas no HW.

1 - before(): transactionalMethods() {

2 - getPm().beginTransaction();

3 - }

4 - public IPersistenceMechanism getPm() {

5 - if (!pmCreated) {6 - if (pm != null) {

7 - pm = pmInit();8 - pmCreated = true;

9 - }

10- }11- return pm;

12-}

Como podemos observar, após a execução do advice before (linha 1), getPmé chamado. Em getPm, pm nunca vai ser iniciado devido à comparação if (pm

!= null)(linha 6). O método getPm retorna null para o advice before quepor sua vez tenta acessar o método beginTransaction() na linha 2 causandoNullPointerException. Este erro foi corrigido a partir da versão 2AO.

O segundo bug foi observado na versão 1AO no caso de teste TC03. Este bugfoi ocasionado devido ao lançamento e o tratamento indevido de uma exceção do tipoNullPointerException. Esta exceção é capturada por um tratador genérico dotipo Exception e remapeada em PersistenceMechanismException e depoisem RepositoryException. No trecho de código abaixo, podemos observar na li-

61

4.3. HEALTH WATCHER

nha 2 a chamada ao método getCommunicationChannel. Este método encerrasua execução lançado NullPointerException devido a tentativa de acessar umarray não incializado. Esta exceção é capturada (linha 3) e remapeada para uma exce-ção do tipo PersistenceMechanismException. Esta exceção é propagada até ométodo ComplaintRepositoryRDB.update que a captura e faz o remapeamentopara RepositoryException.

1- try {

2- return getCommunicationChannel(false).createStatement();

3- } catch (Exception ex) {4- ex.printStackTrace();

5- throw new PersistenceMechanismException(7- ExceptionMessages.EXC_FALHA_GET_CANAL_COMUNICACAO);

8- }

No caso de teste TC05 ainda na versão 1AO a exceção especificada e a exceção captu-rada são diferentes. No trecho de código abaixo temos o fluxo excepcional especificadoneste caso de teste.

String[] trace = new String[]{exception("java.rmi.ConnectException"),

raiseSite("sun.rmi.transport.tcp.TCPEndpoint.newSocket"),

intermediateSite("sun.rmi.transport.tcp.TCPChannel.createConnection"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.newConnection"),

intermediateSite("sun.rmi.server.UnicastRef.newCall"),

intermediateSite("sun.rmi.registry.RegistryImpl_Stub.rebind"),intermediateSite("java.rmi.Naming.rebind"),

catchSite("healthwatcher.business.HealthWatcherFacade.<init>")};

setExceptionPath(trace);

Porém, ao invés de ConnectException uma exceção do tipoStubNotFoundExceptionfoi lançada.

#java.rmi.StubNotFoundExceptionsun.rmi.server.Util.createStub

sun.rmi.server.Util.createProxy

sun.rmi.server.UnicastServerRef.exportObject

62

4.4. CONCLUSÃO

java.rmi.server.UnicastRemoteObject.exportObject

java.rmi.server.UnicastRemoteObject.exportObject

@healthwatcher.aspects.distribution.HWServerDistribution.ajc$around$healthwatcher_aspects_distribution_HWServerDistribution$1$68120162

Este bug foi observado em todas as demais versões avaliadas. O quarto bug , TC06,é similar ao TC02 onde o método singleton nunca instancia o atributo retornado pelométodo (vide bug do TC02). O quinto bug refere-se a uma exceção diferente da esperada.No trecho de código abaixo podemos verificar a especificação do teste.

String[] trace = new String[]{exception("lib.exceptions.PersistenceMechanismException"),

raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),

catchSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),

raiseSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert")

};

Uma exceção do tipo PersistenceMechanismException é esperada e deveser propagada até atingir o método ComplaintRepositoryRDB.insert. Porém,como podemos observar no log de execução do teste, RuntimeException é lançadae propagada até o método ComplaintRepositoryRDB.insert. Esta exceção nãoé capturada forçando o encerramento de sua execução. Este erro foi encontrado nasdemais versões do sistema. O seguinte trecho de código refere-se ao log de execuçãodeste caso de teste.

#java.lang.RuntimeException

healthwatcher.aspects.concurrency.HWTimestamp.updateTimestamp

healthwatcher.data.rdb.ComplaintRepositoryRDB.insert

Os dois últimos erros foram descobertos na décima versão orientada a aspectos doHealth Watcher nos casos de teste TC03 e TC15. A causa do bug é similar ao segundobug (caso de teste TC02). Nestes dois, uma exceção do tipoNullPointerExceptioné lançada e capturada por um tratador genérico sendo remapeada em uma exceção dotipo java.sql.SQLException.

4.4 ConclusãoA abordagem mostrou-se eficaz ao encontrar bugs relacionados ao uso de mecanismosde tratameto de exceção. No total 48 casos de teste foram criados para os três sistemas

63

4.4. CONCLUSÃO

avaliados. Dos 48 casos de testes disponíveis, 33,33% falharam. A abordagem tambémse mostrou eficaz na indicação de alterações de código relativos ao fluxo excepcional.Foi observado que em 6,82% de todas execuções de testes indicam alterações de códigorelacionadas ao fluxo excepcional tais como mudanças de nomes de métodos/pacotes oupela adição ou remoção de nós intermediários. Estas mudanças não significam neces-sariamente que o caso de teste falhou pois são inerentes às atividades de evolução dosistema. Porém permitem que o caso de teste seja revisto tornando a sua especificaçãosempre atualizada.

Devido a características do jUnit o qual falha um teste caso uma exceção seja propa-ganda até o teste, em alguns testes usamos um bloco try-catch envolvendo o método deteste. Esta é uma limitação da versão do jUnitE utilizado na avaliação.

64

5Trabalhos Relacionados

Neste capítulo, apresentamos um conjunto de trabalhos relacionados. Eles são organi-zados em três categorias: (i) Abordagens que utilizam verificação estática de códigorelacionado ao tratamento de exceções; (ii) Abordagens de testes para código de trata-mento de exceções; (iii) Processos de desenvolvimento que integrem exceções no ciclode vida do desenvolvimento de software.

5.1 Verificação EstáticaNa literatura, muitos trabalhos propostos se baseiam em análise estática de código paraverificação do fluxo de exceções [9, 12, 47, 55, 57]. Ferramentas de análise estática defluxo de exceções percorrem o grafo de chamadas com o objetivo de estimar os cami-nhos pelos quais exceções deverão passar em tempo de execução. Chang et al. [9] utilizaanálise estática para estimar os fluxos de exceções com intuito de detectar especificaçõesgerais ou desnecessárias (cláusulas throws ou tratadores catch ) em programas Javaindependentemente da especificação do programador. Yi [40] propõe interpretação abs-trata para estimar exceções não capturadas (uncaught exceptions) em programas ML.Fähndrich et al. [47] desenvolveu um toolkit chamado BANE para descobrir exceçõesnão capturadas em programas ML. Robillard e Murphy propuseram uma abordagempara simplificar a estrutura das exceções em programas Java [55]. Também foi desen-volvido por eles a ferramenta JEX. Esta ferramenta extrai informações sobre o fluxo deexceções através da propagação de informação sobre tipos de exceções lançadas pelografo de chamadas de métodos, fornecendo uma visão dos tipos de exceção que possamsurgir em pontos diferentes do programa. Fu e Ryder [12] propuseram a ideia de análiseda cadeia de exceções (do inglês: exception-chain analysis), como forma de diminuir osresultados produzidos por ferramentas como Jex. Análise da cadeia de exceções tem por

65

5.2. ABORDAGENS BASEADAS NO TESTE DO COMPORTAMENTOEXCEPCIONAL

objetivo reduzir o número dos caminhos de propagação das exceções através da fusãodos caminhos excepcionais relacionados.

Outras ferramentas foram criadas a fim de facilitar a compreensão da análise de fluxoexcepcional. A ferramenta JEXVIS [70] utiliza informação textual para gerar uma visu-alização interativa da estrutura da exceção. Esta ferramenta é baseada no Jex com modi-ficações para que produza uma saída textual na forma de grafo. A ferramenta EXTEST[12] apresenta uma visão em forma de árvore dos tratadores de exceção, seus gatilhos eos caminhos de propagação das exceções. Esta também permite a navegação no códigode tratamento de exceções. EXPO [68] calcula estatísticas de tratamento de exceções evisualiza o contexto dos pares throw-catch como um gráfico de fluxo. Estas duasultimas ferramentas estão disponíveis na forma de plugins para o Eclise. A ferramentaENHANCE [29] apresenta formas de visualização diferentes para as exceções em umsistema (Quantitative View, Flow View e Contextual View).

A principal limitação das abordagens de análise estática, bem como as ferramentasde visualização associadas, é que eles apóiam a descoberta mas não a execução dos cami-nhos excepcionais. Podemos verificar outra dificuldade. Digamos que um programa foimodificado. Os desenvolvedores utilizam analise estática para compreender a estruturados fluxos excepcionais. Neste caso, uma grande quantidade de esforço pode ser gastapara descobrir como as mudanças no código do programa podem ter afetado os fluxosexcepcionais percorridos pelas exceções. Ao mesmo tempo, devido a fatores tais comoherança e polimorfismo, estas ferramentas muitas vezes relatam muitos falsos positivos.Um outro problema deve-se ao fato da análise estática ser útil apenas quando o sistemajá foi implementado, portanto não pode ajudar nas atividades de especificação e projetode sistemas novos.

5.2 Abordagens baseadas no teste do comportamento ex-cepcional

O JUnit é um framework de testes amplamente utilizado, ele permite verificar se umpedaço de código que deveria lançar uma determinada exceção realmente a lança. Estaverificação é realizada em tempo de execução através da execução de um caso de teste.Porém o JUnit não oferece qualquer construção que permita ao desenvolvedor verificarse um fluxo excepcional ocorrido durante a exceção de um caso de teste é o esperado.Também não é possível determinar se um tratador especifico capturou uma determinadaexceção.

66

5.3. ABORDAGEM BASEADA NO PROCESSO DE DESENVOLVIMENTO

Sales et al. [63, 64] , propõem uma abordagem para apoiar a definição e teste doscontratos de tratamento de exceção. Um contrato de tratamento de exceção especificaos elementos responsáveis por sinalizar exceções e elementos responsáveis por tratá-las.Nesta abordagem, os casos de testes para o JUnit são parcialmente gerados partir de taiscontratos.

Nossa abordagem leva em conta o fato de que o efeito global de uma ocorrênciaexcepcional deve considerar os locais intermediários por onde a exceção pode ser propa-gada antes de alcançar seu tratador. Esta característica difere da proposta anterior poispodemos especificar o local onde a exceção é laçada, o caminho percorrido por esta exce-ção e onde será tratada. Além disso, nós adicionamos novas construções no JUnitE a fimde permitir a definição e verificação do fluxo excepcional percorrido por uma exceçãona execução de um caso de teste.

5.3 Abordagembaseada no processo de desenvolvimentoPoucas abordagens têm sido propostas visando a definição do comportamento de trata-mento de exceção em todas as atividades de desenvolvimento de software antes mesmoda implementação do sistema.

Algumas delas incorporam atividades de tratamento de exceções em metodologiasexistentes de desenvolvimento de software [26, 53], enquanto outras têm como alvoatividades especificas de desenvolvimento ( requisitos [5], projeto arquitetural [21, 42]).As três primeiras abordagens [5, 26, 53] possuem uma forte ênfase na produção dedocumentação sobre o comportamento excepcional.

Para a nossa abordagem, consideramos a ênfase na produção de documentação sobreo comportamento excepcional como uma limitação. É bem conhecido que os desenvol-veres muitas vezes não mantêm a documentação atualizada durante a implementação eevolução do sistema [39]. Por essa razão, a nossa abordagem baseia-se na definiçãode testes automatizados, a fim de especificar o comportamento do código de tratamentode exceção. Esta especificação também serve como documentação, pois sempre estaráatualizada, caso contrário o caso de teste falha.

No trabalho de Rubira et al. [26] e Brito et al. [53], são apresentadas diretrizes paraa especificação da atividade excepcional de um sistema desde as fases iniciais de desen-volvimento, com enfoque maior nas fases de definição de requisitos análise e projeto.Brito et al. [53] refinam o trabalho de Rubira et al. [26], principalmente no projeto ar-quitetural, na elaboração e na execução de testes, tendo em vista que o trabalho anterior

67

5.3. ABORDAGEM BASEADA NO PROCESSO DE DESENVOLVIMENTO

não aborda profundamente tais assuntos.Castor et al. [21] propõem uma solução para especificar e verificar o fluxo de con-

trole de exceções na arquitetura de software utilizando a linguagem de especificaçãoAlloy [16]. Esta especificação contém informações sobre o fluxo de exceção baseadasem um modelo formal. Isto possibilita verificar se a arquitetura satisfaz algumas propri-edades de interesse em relação ao fluxo de exceção antes mesmo da implementação dosistema.

Brito et. al. [42] apresentam uma abordagem de desenvolvimento baseado emmétodos formais. Esta permite sistematizar a verificação do comportamento anormal dosistema a nível arquitetural. Esta abordagem se baseia na especificação e verificação decenários arquiteturais, os quais descrevem controle de fluxo de exceções e tratamento deexceções nos elementos arquiteturais. O trabalho de Brito et al. [66] tem como focoprincipal a extração de casos de testes diretamente da representação formal da arquiteturado sistema permitindo a análise da propagação de erros, a nível da implementação sob aperspectiva da arquitetura do sistema.

68

6Considerações Finais

Este capítulo apresenta as considerações finais desta dissertação assim como o direcio-namento para trabalhos futuros. As contribuições da abordagem proposta e publicaçõesrelacionadas também são apresentadas neste capítulo.

6.1 ConclusãoEngenheiros de software se deparam com a difícil tarefa de desenvolver, depurar e man-ter sistemas de software que contém construções de tratamento de exceção. Lidar comexceções desde o início do desenvolvimento de software permite a engenheiros de soft-ware produzirem código de tratamento de exceções mais robusto. Porém não é dada adevida atenção ao comportamento excepcional nas fases de especificação do software.Isso leva os engenheiros de software a criarem o seu código de tratamento de exceçõesde maneira pontual não levando em conta o efeito global de uma exceção.

Também, em alguns casos, somos confrontados com os sistemas existentes que re-queremmanutenção. Estes em sua maioria não levam em contra o comportamento excep-cional antes da implementação do sistema. Contudo as abordagens de desenvolvimentoexistentes não dão suporte à especificação do comportamento excepcional para sistemaexistentes o que impossibilita o seu acompanhamento durante a evolução de um sistema.

Um outro problema deve-se ao fato dos engenheiros de software acharem que os me-canismos de tratamento de exceções podem complicar os programas pois estes exigemuma visão global do sistema. Para entender como uma exceção afeta a execução de umprograma, não é suficiente olhar para um ponto especifico do código do programa. É im-portante determinar qual o fluxo excepcional está relacionado a um ponto do programa ede onde a exceção é originada. Porém os mecanismos existentes de tratamento de exce-ção possuem foco local não dando suporte ao entendimento do fluxo excepcional como

69

6.2. PUBLICAÇÕES RELACIONADAS

um todo.Para isso, propusemos uma nova abordagem para especificação e teste do comporta-

mento excepcional. Esta é capaz de revelar todo o fluxo excepcional dada a ocorrênciade uma exceção permitindo verificar os efeitos de uma exceção de maneira global. Atra-vés da especificação de testes automatizados, permite a verificação do comportamentoesperado a fim de verificar se o fluxo ocorrido está correto. Para apoiar esta abordagem,nós desenvolvemos uma extensão do framework JUnit denominada JUnitE.

A abordagem de teste proposta nos ajudou a descobrir uma série de bugs para trêssistemas avaliados neste trabalho. A abordagem se mostrou eficaz na descoberta de bugsnovos não reportados nas bases de bug report destes projetos bem como detectou bugsjá reportados.

6.2 Publicações relacionadasEste trabalho permitiu a publicação de dois artigos até o momento da defesa desta dis-sertação:

• Towards Agile Testing of Exceptional Behavior [59]: Este artigo faz uma apresen-tação preliminar da abordagem proposta.

• Agile Testing of Exceptional Behavior [58]: Este artigo apresenta a abordagemproposta e analisa os resultados de dois sistemas avaliados: aTunes e jEdit. Esterecebeu o prémio de teceiro melhor artigo do Simpósio Brasileiro de Engenhariade Software em 2011.

6.3 Trabalhos futurosPropomos cinco linhas de trabalho futuro. Primeiro, temos a intenção de realizar maisestudos de casos a fim de complementar os resultados obtidos. Em segundo lugar, gosta-ríamos de realizar estudos de caso adicionais para avaliar a abordagem para uma linha deproduto de software. Em terceiro lugar, gostaríamos de realizar um experimento contro-lado com dois grupos de desenvolvedores para construir um sistema a partir do zero, umdeles usando nossa abordagem de teste e outro não usá-lo. Em quarto lugar gostaríamosde automatizar a criação dos casos de testes em dois cenários distintos. O primeiro delesquando já dispomos da implementação do sistema com o objetivo de facilitar o uso daferramenta bem como diminuir o tempo investido na especificação dos casos de testes

70

6.3. TRABALHOS FUTUROS

iniciais. No segundo cenário, permitir a geração dos casos de testes para sistemas novosutilizando como entrada os artefatos de arquitetura gerados. Finalmente, em quinto lu-gar, gostaríamos de avaliar como casos de teste relativos ao comportamento excepcionalpodem complementar as técnicas de análise estática.

71

Referências Bibliográficas

[1] Object management group: Unified modeling language specification version 1.5,2003.

[2] Avizienis, A. Design of fault-tolerant computers. volume v.31, pages p.733–743,1967.

[3] Avizienis, A. Toward systematic design of fault-tolerant systems. volume 30, pages51–58, Los Alamitos, CA, USA, 1997. IEEE Computer Society.

[4] Garcia, A., Chavez, C., Batista, T. V. B, Sant’Anna, C., Kulesza, U., Rashid, A.,and Lucena, C. J. P. On the modular representation of architectural aspects. InEWSA, pages 82–97, 2006.

[5] Shui, A., Mustafiz, S., and Kienzle, J. Exception-aware requirements elicitationwith use cases. In Advanced Topics in Exception Handling Techniques, pages 221–242, 2006.

[6] Cacho, N. andCastor Filho, F., Garcia, A, and Figueiredo, E. EJFlow: taming ex-ceptional control flows in aspect-oriented programming. In Proceedings of the 7thinternational conference on Aspect-oriented software development, March, 2008.

[7] Beizer, B. Black-box testing - techniques for functional testing of software andsystem. 1995.

[8] Cabral, B. and Marques, P. Exception Handling: A Field Study in Java and .NET.pages 151–175, 2007.

[9] Chang, B., Jo, J., Yi, K, and Choe, K. Interprocedural exception analysis for java.In Proceedings of the 2001 ACM symposium on Applied computing, pages 620–625, New York, NY, USA, 2001. ACM.

[10] Goodenough, J. B. Structured exception handling. In POPL, pages 204–224, 1975.

[11] Meyer, B. Object-Oriented Software Construction. Prentice-Hall, Inc., UpperSaddle River, NJ, USA, 1988.

[12] Fu, C. and Barbara, G. Exception-chain analysis: Revealing exception handlingarchitecture in java server applications. In Proceedings of the 29th internationalconference on Software Engineering, ICSE ’07, pages 230–239, Washington, DC,USA, 2007. IEEE Computer Society.

72

REFERÊNCIAS BIBLIOGRÁFICAS

[13] Guerra, P. A. C., Rubira, C. M. F., and Lemos, R. Architecting dependable systems.pages 129–149, Berlin, Heidelberg, 2003. Springer-Verlag.

[14] Misra, S. C., Kumar, V., and Kumar, U. Identifying some important success factorsin adopting agile software development practices. volume 82, pages 1869–1890,New York, NY, USA, November 2009. Elsevier Science Inc.

[15] Silva Jr, M. C., Guerra, P. A. C., and Rubira, C. M. F. A java component model forevolving software systems. In ASE, pages 327–330, 2003.

[16] Jackson, D. Alloy: a lightweight object modelling notation. volume 11, pages256–290. ACM, April 2002.

[17] Janzen, D. and Saiedian, H. Test-driven development: Concepts, taxonomy, andfuture direction. IEEE Computer, 38(9):43–50, 2005.

[18] Gamma, E. and Beck, K. Junit. Acessado em Novembro de 2010http://www.junit.org/.

[19] Castor Filho, F., Cacho, N., Maranhão, R., Figueiredo, E., Garcia, A., and Rubira,C.M.F. Exceptions and aspects: The devil is in the details. 2006.

[20] Castor Filho, F., Brito, P. H. S., and Rubira, C. M. F. A framework for analyzingexception flow in software architectures. volume 30, pages 1–7, 2005.

[21] Castor Filho, F., Brito, P. H. S, and Rubira, C. M. F. Reasoning about exceptionflow at the architectural level. In RODIN Book, pages 80–99, 2006.

[22] Castor Filho, F. Guerra, P. A. C. Rubira, C. M. F. A systematic approach forstructuring exception handling in robust component-based software. 2005.

[23] Cristian, F. Exception handling and software fault tolerance. volume 31, pages531–540, Washington, DC, USA, 1982. IEEE Computer Society.

[24] Cristian, F. Exception Handling and Tolerance of Software Faults, volume 31.Software Fault Tolerance, Washington, DC, USA, 1994.

[25] Garcia, A. F., Rubira, C. M. F., Romanovsky, A., and Xu, J. A comparative study ofexception handling mechanisms for building dependable object-oriented software,2001.

73


[26] Rubira, C. M. F., Lemos, R., Ferreira, G. R. M., and Castor Filho, F. Exceptionhandling in the development of dependable component-based systems. volume 35,pages 195–236, New York, NY, USA, 2005. John Wiley & Sons, Inc.

[27] The Jakarta Foundation. Cactus, a thorn in your bug’s side. Acessado em Abril de2011.

[28] Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J, and Griswold, W. G.Aspect-oriented programming with aspectj. In In Proc. 15th European Conf. onObject-Oriented Programming (ECOOP). Springer-Verlag, 2001.

[29] Shah, H., Görg, C., and Harrold, M. J. Visualization of exception handling cons-tructs to support program understanding. In Proceedings of the 4th ACM sympo-sium on Software visualization, SoftVis ’08, pages 19–28, New York, NY, USA,2008. ACM.

[30] Shah, H., Görg, C, and Harrold, M. J. Why do developers neglect exception han-dling? In Proceedings of the 4th international workshop on Exception handling,pages 62–68, New York, NY, USA, 2008. ACM.

[31] Ferreira, J., Martins, E., Rubira, C. M. F., and Brito, P. H. S. Validation of exceptionhandling in the development of dependable component-based software systems. InLADC, pages 136–145, 2011.

[32] Kienzle, J. On exceptions and the software development life cycle. In WEH ’08:Proceedings of the 4th international workshop on Exception handling, pages 32–38, New York, NY, USA, 2008. ACM.

[33] Laprie, J. pages 1–44.

[34] Laprie, J. Dependable computing and fault tolerance: Concepts and terminology.volume 3, pages p.2–11, 1995.

[35] Myers, G. J. The art of software testing. 1979.

[36] Myers, G. J. and Sandler, C. The Art of Software Testing. John Wiley & Sons,2004.

[37] Shore, J. andWarden, S. The art of agile development. O’Reilly, first edition, 2007.

74


[38] Beck, K. Aim, fire. volume 18, pages 87–89, Los Alamitos, CA, USA, 2001. IEEEComputer Society.

[39] Beck, K. and Andres, C. Extreme Programming Explained: Embrace Change (2ndEdition). Addison-Wesley Professional, 2004.

[40] Yi, K. An abstract interpretation for estimating uncaught exceptions in standard mlprograms. volume 31, pages 147–173, Amsterdam, The Netherlands, The Nether-lands, May 1998. Elsevier North-Holland, Inc.

[41] Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Addison-Wesley Professional, 1997.

[42] Brito, P. L. and Rubira, C.M.F. Verification of exception control flows and han-dlers based on architectural scenarios. In High Assurance Systems EngineeringSymposium, 2008. HASE 2008. 11th IEEE, pages 177 –186, dec. 2008.

[43] Parnas, D. L. On the criteria to be used in decomposing systems into modules.volume 15, pages 1053–1058, New York, NY, USA, 1972. ACM.

[44] Parnas, D. L. and Würges, H. Response to undesired events in software systems.IEEE Computer Society Press, Los Alamitos, CA, USA, 1976.

[45] Ramnivas, L. AspectJ in Action: Practical Aspect-Oriented Programming. Man-ning Publications Co., Greenwich, CT, USA, 2003.

[46] Delamaro, M., Maldonado, J. C, and Jino, M. Introdução ao Teste de Software.Elsevier Rio de Janeiro, 2007.

[47] Fahndrich, M., Foster, J., Cu, J., and Aiken, A. Tracking down exceptions in stan-dard ml programs. Berkeley, CA, USA, 1998. University of California at Berkeley.

[48] Lippert, M. and Lopes, C. V. A study on exception detection and handling usingaspect-oriented programming. In ICSE ’00: Proceedings of the 22nd internationalconference on Software engineering, pages 418–427, New York, NY, USA, 2000.ACM.

[49] Pinto, M., Gamez, N., and Fuentes, L. Towards the architectural definition of thehealth watcher system with ao-adl. In Proceedings of the Early Aspects at ICSE:Workshops in Aspect-Oriented Requirements Engineering and Architecture Design,

75


EARLYASPECTS ’07, pages 5–, Washington, DC, USA, 2007. IEEE ComputerSociety.

[50] Cacho, N., Castor Filho, F., Garcia, A., and Figueiredo, E. EJFlow: taming excep-tional control flows in aspect-oriented programming. ACM, New York, NY, USA,2008.

[51] Cacho, N., Cottenier, T., and Garcia, A. Improving robustness of evolving excep-tional behaviour in executable models. In Proceedings of the 4th internationalworkshop on Exception handling, WEH ’08, pages 39–46, New York, NY, USA,2008. ACM.

[52] Alves, M. P., Pires, P. F., and Delicato, F. C. Crossmda: Arcabouço para integraçãode interesses transversais no desenvolvimento orientado a modelos. 2007.

[53] Brito, P., Rocha, C.R., Castor Filho, F., Martins, E., and Rubira, C.M.F. A methodfor modeling and testing exceptions in component-based software development. InDependable computing: second Latin-American symposium, LADC 2005, Salva-dor, Brazil, October 25-28, 2005: proceedings, page 61. Springer Verlag, 2005.

[54] Robillard, M. P. and Murphy, G. C. Designing robust java programs with excepti-ons. In SIGSOFT ’00/FSE-8: Proceedings of the 8th ACM SIGSOFT internationalsymposium on Foundations of software engineering, pages 2–10, New York, NY,USA, 2000. ACM.

[55] Robillard, M. P. and Murphy, G. C. Static analysis to support the evolution ofexception structure in object-oriented systems. volume 12, pages 191–221, NewYork, NY, USA, April 2003. ACM.

[56] Partington. Partington, v. middleware integration testing with junit, maven andvmware. Acessado em Abril de 2011.

[57] Coelho, R., Awais, R. andGarcia, A., Ferrari, F., , N. Cacho, Kulesza, U., Staa, A.,and Lucena, C. Assessing the impact of aspects on exception flows: An explora-tory study. In Proceedings of the 22nd European conference on Object-OrientedProgramming, ECOOP ’08, pages 207–234. Springer-Verlag, 2008.

[58] Di Bernardo, R, Castor Filho, F., Sales Junior, R. andCoelho, R, and Cacho, N.andSoares, S. Agile testing of exceptional behavior. aug 2011.

76


[59] Di Bernardo, R., Castor Filho, F., and Soares, S. Towards agile testing of excep-tional behavior. In EHCoS 2011, São José dos Campos, São Paulo, Brazil, jan2011.

[60] Lemos, R. Architecting dependable systems iv. pages 142–162, Berlin, Heidelberg,2007. Springer-Verlag.

[61] Lemos, R, Guerra, P. A. C., and Rubira, C. M. F. A fault-tolerant architecturalapproach for dependable systems. volume 23, pages 80–87, Los Alamitos, CA,USA, March 2006. IEEE Computer Society Press.

[62] Rocha, C. R. and Martins, E. A method for model based test harness generationfor component testing. volume 14, pages 7–23, 2008.

[63] Sales Junior, R. and Coelho, R. Preserving the exception handling design rulesin software product line context: A practical approach. Dependable ComputingWorkshops, Latin-American Symposium on, 0:9–16, 2011.

[64] Sales Junior, R., Coelho, R.., and Lustosa Neto, V. Exception-aware ao refactoring.2010.

[65] Brito, P. H. S., Lemos, R., Martins, E., and Rubira, C. M. F. Architecture-centricfault tolerance with exception handling. In LADC, pages 75–94, 2007.

[66] Brito, P. H. S, Lemos, R., Martins, E., Moraes, R. L. O., and Rubira, C. M. F.Architectural-based validation of fault-tolerant software. In LADC, pages 103–110,2009.

[67] Rapps, S. and Weyuker, E. J. Data flow analysis techniques for test data selection.In Proceedings of the 6th international conference on Software engineering, ICSE’82, pages 272–278, Los Alamitos, CA, USA, 1982. IEEE Computer Society Press.

[68] Sinha, S., Orso, A., and Harrold, M. J. Automated support for development, main-tenance, and testing in the presence of implicit control flow. In Proceedings of the26th International Conference on Software Engineering, ICSE ’04, pages 336–345,Washington, DC, USA, 2004. IEEE Computer Society.

[69] Sinha, S. and Harrold, M. J. Criteria for testing exception-handling constructs injava programs. In Proceedings of the IEEE International Conference on SoftwareMaintenance, ICSM ’99, pages 265–, Washington, DC, USA, 1999. IEEE Compu-ter Society.

77


[70] Sinha, S. and Harrold, M. J. Analysis and testing of programs with exceptionhandling constructs. volume 26, pages 849–871, Piscataway, NJ, USA, September2000. IEEE Press.

[71] Soares, S., Laureano, E, and Borba, P. Implementing distribution and persistenceaspects with aspectj. In Proceedings of the 17th ACM SIGPLAN conference onObject-oriented programming, systems, languages, and applications, OOPSLA’02, pages 174–190, New York, NY, USA, 2002. ACM.

[72] Soares, S., Laureano, E., and Borba, P. Implementing distribution and persistenceaspects with aspectj. In OOPSLA, pages 174–190, 2002.

[73] Soares, S. and Borba, P. Aspect-oriented implementation method, 2004.

[74] Weber, T. S. Tolerância a falhas: conceitos e exemplos. Acessado em Fevereiro de2010 http://www.inf.ufrgs.br/ taisy/disciplinas/textos/index.html.

[75] Anderson, T. and Lee, P. A. Fault Tolerance: Principles and Practice. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 1990.

[76] Cargill, T. Exception handling: a false sense of security. pages 423–431, NewYork, NY, USA, 1996. SIGS Publications, Inc.

[77] Elrad, T., Aksit, M., Kiczales, G., Lieberherr, K. J., and Ossher, H. Discussingaspects of aop. volume 44, pages 33–38, 2001.

[78] McCune, T. T. exception-handling antipatterns, 2006. in java.net. Acessado em Se-tembro de 2010 http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html, 2006.

[79] Kulesza, U., Sant’Anna, C., Garcia, A., Coelho, R., and [von Staa.

[80] Dijkstra, E. W. A discipline of programming (prentice hall). 1976.

78

Apêndice

ACasos de teste

A.1 Atunes

A.1.1 Atunes 1.5 TC01@PartialSequencialModepublic class TC01 extends JunitETestCase {

/*** Pre-condition: Internet access and weaving aspect ...TC01

*/@Test@FaultInjection(exception = "java.io.IOException",

method = "net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL",methodReturnType = "java.lang.String",methodParType = "java.net.URLConnection")

public void testTC001() {

// Specifies the desired exception pathString[] trace = new String[] {

exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules." +"network.NetworkUtils.readURL"),

catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler." +"AudioScrobblerService.getSimilarArtists") };

super.setExceptionPath(trace);

// Sets the exception pathAudioScrobblerService service = null;

// Calls the element that should handle the exceptiontry {

service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.google.com", 80, "teste", "1234"));

service.getSimilarArtists("Bob");} catch (UnknownHostException e) {

e.printStackTrace();} catch (IOException e) {

e.printStackTrace();}

}}

80

A.1. ATUNES

A.1.2 Atunes 1.5 TC02@FullSequencialModepublic class TC02 extends JunitETestCase {

/*** Pre-condition: Internet access

*/@Testpublic void testTC002() {

String[] trace = new String[] {exception("java.io.IOException"),raiseSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };


// Start time measurementTimer.start();

// Fetch arguments into a listArrayList<String> arguments = StringUtils

.fromStringArrayToList(new String[] { "" });

// Set log4j propertiesLog4jPropertiesLoader.loadProperties(Kernel.DEBUG,

arguments.contains("multiple_log"));

// Start the Kernel, which really starts applicationKernel.startKernel();

AmazonService service = new AmazonService(null);service.getAlbum("Teste", "Teste");

}}

A.1.3 Atunes 1.5 TC03/*** Precondition: Disable Internet connection.

*/public class TC03 extends JunitETestCase {

@Testpublic void testTC003() {

String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };








AmazonService.getAlbum("Teste", "Teste");

81

A.1. ATUNES

}}

A.1.4 Atunes 1.5 TC04PartialSequencialModepublic class TC04 extends JunitETestCase {

@Testpublic void testTC004_1() {

String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),"java.io.FileInputStream.<init>","net.sourceforge.atunes.kernel.modules.tags.reader.ID3v2TagReader.retrieveTag","net.sourceforge.atunes.kernel.modules.tags.reader.TagReader.readFile",catchSite("net.sourceforge.atunes.kernel.modules.tags.reader.TagDetector.getTags") };


try {new AudioFile("c:\\invalid.mp3");

} catch (FileNotFoundException e) {e.printStackTrace();

}}


String[] trace = new String[] {exception("entagged.audioformats.exceptions.CannotReadException"),raiseSite("entagged.audioformats.generic.AudioFileReader.read"),catchSite("net.sourceforge.atunes.model.audio.AudioFile.readDuration") };


try {new AudioFile("c:\\invalid.mp3");


}}

}



String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),intermediateSite("net.sourceforge.atunes.kernel.modules.tags.reader.ID3v1_1TagReader.retrieveTag"),intermediateSite("net.sourceforge.atunes.kernel.modules.tags.reader.TagReader.readFile") };


ID3v1_1TagReader v1_1Reader = new ID3v1_1TagReader();try {

v1_1Reader.readFile(new AudioFile("c:\\invalid.mp3"));} catch (FileNotFoundException e) {



}}

82

A.1. ATUNES



String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),intermediateSite("net.sourceforge.atunes.kernel.modules.tags.reader." +"ID3v1TagReader.retrieveTag"),

intermediateSite("net.sourceforge.atunes.kernel.modules.tags.reader." +"TagReader.readFile") };


ID3v1TagReader v3_1Reader = new ID3v1TagReader();try {

v3_1Reader.readFile(new AudioFile("c:\\invalid.mp3"));} catch (FileNotFoundException e) {



}}



String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("sun.net.www.http.HttpClient.<init>"),intermediateSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.getImage"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getImage") };








AmazonService.getAmazonImage("http://teste");}

}

83

A.1. ATUNES



String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("java.net.SocksSocketImpl.connect"),intermediateSite("java.net.Socket.connect"),intermediateSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.<init>"),catchSite("net.sourceforge.atunes.kernel.handlers.AudioScrobblerServiceHandler.updateService") };


Kernel.startKernel();

int port = 1010;String type = ProxyBean.HTTP_PROXY;ProxyBean proxy = new ProxyBean();proxy.setUrl("http://teste");proxy.setPort(port);proxy.setUser("teste");proxy.setPassword(new String("teste"));proxy.setType(type);

HandlerProxy.getAudioScrobblerServiceHandler().updateService(proxy);}

}

A.1.9 Atunes 1.5 TC09*** Precondition: Choose a valid image and press save.


@Test@FaultInjection(exception = "java.io.IOException",

method = "net.sourceforge.atunes.kernel.utils.PictureExporter.doExport",methodReturnType = "void", methodParType = "..")

public void testTC009() {String[] trace = new String[] {

exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.PictureExporter.doExport"),intermediateSite("net.sourceforge.atunes.kernel.utils.PictureExporter.exportPicture"), };


try {PictureExporter.exportPicture(new AudioFile("c:\\invalid.mp3"));

} catch (ImageFormatException e) {e.printStackTrace();


} catch (IOException e) {e.printStackTrace();

}}

}

84

A.1. ATUNES

A.1.10 Atunes 1.5 TC10/*** Precondition: Internet connection.



method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.URLConnection", methodParType = "..")


exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.getConnection"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists") };


AudioScrobblerService service = null;try {

service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.youtube.com", 80, "teste", "1234"));




}}

A.1.11 Atunes 1.5 TC11FaultInjection(exception = "java.io.IOException",

method = "net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture",methodReturnType = "void", methodParType = "..")

@PartialSequencialModepublic class TC11 extends JunitETestCase {


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture"),catchSite("net.sourceforge.atunes.kernel.handlers.RipperHandler.savePicture") };


HandlerProxy.getRipperHandler().savePicture(null, new File(""), "", "");}

}

A.1.12 Atunes 1.5 TC12

@PartialSequencialModepublic class TC12 extends JunitETestCase {

@Test@FaultInjection(exception = "java.net.MalformedURLException",

method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "class java.net.URL",

85

A.1. ATUNES

methodParType = "java.lang.String")


exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.search.SearchFactory$1.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.SearchInternetHandler.openSearch"),




exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.search.SearchFactory$5.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.SearchInternetHandler.openSearch") };


SearchInternetHandler.openSearch(SearchFactory.youTubeSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.wikipediaENSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.freeDBSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.musicBrainzSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.googleVideoSearch, "U2");

}}

A.1.13 Atunes 1.5 TC14@Test

public void testTCCur() {


exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("java.net.Socket.connect"),intermediateSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.<init>") };




service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.invalid.inv", 80, "teste", "1234"));




}

}

86

A.1. ATUNES

A.1.14 Atunes 1.6 TC01PartialSequencialMode/*** Precondition: Internet access and weaving aspect ...TC01



method = "net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL",methodReturnType = "java.lang.String", methodParType = "java.net.URLConnection")

public void testTC01() {/*** Execution Trace #java.io.IOException

* net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL

** @net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists

*/String[] trace = new String[] {

exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists") };



service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"));




}

}

A.1.15 Atunes 1.6 TC02/*** OBS: Teste requer conexÃ£o com a internet.

*/@PartialSequencialModepublic class TC02 extends JunitETestCase {


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };







87

A.1. ATUNES



}}

A.1.16 Atunes 1.6 TC03@PartialSequencialMode

/*** Precondition: Disable Internet connection.



String[] trace = new String[]{exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"), //...intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum")};setExceptionPath(trace);


// Fetch arguments into a listArrayList<String> arguments = StringUtils.fromStringArrayToList(new String[]{""});

// Set log4j propertiesLog4jPropertiesLoader.loadProperties(Kernel.DEBUG, arguments.contains("multiple_log"));


AmazonService service = new AmazonService(null);service.getAlbum("Teste", "Teste");}}



String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),"java.io.FileInputStream.<init>","net.sourceforge.atunes.kernel.modules.repository.tags.reader.ID3v2TagReader.retrieveTag","net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagReader.readFile",catchSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagDetector.getTags")};setExceptionPath(trace);

TagDetector.getTags(new AudioFile("c:\\invalid.mp3"));

88

A.1. ATUNES

}

@Testpublic void testTC04_2() {String[] trace = new String[] {exception("entagged.audioformats.exceptions.CannotReadException"),raiseSite("entagged.audioformats.generic.AudioFileReader.read"),catchSite("net.sourceforge.atunes.kernel.modules.repository.audio.AudioFile.readAudioProperties")};setExceptionPath(trace);

TagDetector.getTags(new AudioFile("c:\\invalid.mp3"));}}


@Testpublic void testTC05() {String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),intermediateSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.ID3v1_1TagReader.retrieveTag"),intermediateSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagReader.readFile") };setExceptionPath(trace);

ID3v1_1TagReader v1_1Reader = new ID3v1_1TagReader();try {v1_1Reader.readFile(new AudioFile("c:\\invalid.mp3"));} catch (FileNotFoundException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}


@Testpublic void testTC06() {String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),intermediateSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.ID3v2TagReader.retrieveTag"),intermediateSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagReader.readFile") };setExceptionPath(trace);

ID3v1TagReader v3_1Reader = new ID3v1TagReader();try {v3_1Reader.readFile(new AudioFile("c:\\invalid.mp3"));} catch (FileNotFoundException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}

89

A.1. ATUNES


@Testpublic void testTC07() {String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("sun.net.www.http.HttpClient.<init>"),intermediateSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.getImage"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getImage") };setExceptionPath(trace);


// Fetch arguments into a listArrayList<String> arguments = StringUtils.fromStringArrayToList(new String[] { "" });

// Set log4j propertiesLog4jPropertiesLoader.loadProperties(Kernel.DEBUG,arguments.contains("multiple_log"));


AmazonService.getAmazonImage("http://teste");}}



String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("java.net.SocksSocketImpl.connect"),intermediateSite("java.net.Socket.connect"),intermediateSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.<init>"),catchSite("net.sourceforge.atunes.kernel.handlers.AudioScrobblerServiceHandler.updateService") };setExceptionPath(trace);

Kernel.startKernel();int port = 1010;String type = ProxyBean.HTTP_PROXY;ProxyBean proxy = new ProxyBean();proxy.setUrl("http://teste");proxy.setPort(port);proxy.setUser("teste");proxy.setPassword(new String("teste"));proxy.setType(type);

HandlerProxy.getAudioScrobblerServiceHandler().updateService(proxy);}

}

90

A.1. ATUNES

A.1.22 Atunes 1.6 TC09public class TC09 extends JunitETestCase{

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.utils.PictureExporter.doExport",methodReturnType = "void",methodParType = "..")public void startup() {

String[] trace = new String[]{exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.PictureExporter.doExport"),intermediateSite("net.sourceforge.atunes.kernel.utils.PictureExporter.exportPicture")};setExceptionPath(trace);

try {PictureExporter.exportPicture(new AudioFile("c:\\invalid.mp3"));} catch (ImageFormatException e) {e.printStackTrace();} catch (FileNotFoundException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}


/*** Precondition: Internet access.

*/public class TC10 extends JunitETestCase{

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.URLConnection",methodParType = "..")public void testTC10() {

String[] trace = new String[]{exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.modules.network.NetworkUtils.getConnection"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists")};setExceptionPath(trace);

AudioScrobblerService service = null;try {service = new AudioScrobblerService(new Proxy(Type.HTTP, "www.google.com", 80, "teste", "1234"));service.getSimilarArtists("Bob");} catch (UnknownHostException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}

91

A.1. ATUNES

A.1.24 Atunes 1.6 TC11

@PartialSequencialModepublic class TC11 extends JunitETestCase{

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture",methodReturnType = "void",methodParType = "..")public void testTC11() {

String[] trace = new String[]{exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture"),catchSite("net.sourceforge.atunes.kernel.handlers.RipperHandler.savePicture")};setExceptionPath(trace);

HandlerProxy.getRipperHandler().savePicture(null,new File(""), "", "");}}

A.1.25 Atunes 1.6 TC12@PartialSequencialModepublic class TC12 extends JunitETestCase{

@Test@FaultInjection(exception = "java.net.MalformedURLException",method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "class java.net.URL",methodParType = "java.lang.String")public void testTE12() {String[] trace = new String[]{exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.search.SearchFactory$1.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.SearchInternetHandler.openSearch"),




exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.search.SearchFactory$5.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.SearchInternetHandler.openSearch")};setExceptionPath(trace);

try {SearchInternetHandler.openSearch(SearchFactory.youTubeSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.wikipediaENSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.freeDBSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.musicBrainzSearch, "U2");SearchInternetHandler.openSearch(SearchFactory.googleVideoSearch, "U2");} catch (Exception e) {e.printStackTrace();}}}

92

A.1. ATUNES

A.1.26 Atunes 1.6 TC14public class TC14 extends JunitETestCase {

@Testpublic void testTCCur() {

// Specifies the desired exception pathString[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("java.net.Socket.connect"),intermediateSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.<init>") };



// Calls the element that should handle the exceptiontry {service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.invalid.inv", 80, "teste", "1234"));service.getSimilarArtists("Bob");} catch (UnknownHostException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}

A.1.27 Atunes 1.9 TC01@PartialSequencialModepublic class TC01 extends JunitETestCase{

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.network.NetworkUtils.readURL",methodReturnType = "java.lang.String",methodParType = "java.net.URLConnection")public void testTC01() {String[] trace = new String[]{exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists")};setExceptionPath(trace);

AudioScrobblerService service = null;try {service = new AudioScrobblerService(new Proxy(Type.HTTP, "www.google.com", 80, "teste", "1234"));service.getSimilarArtists("Bob");} catch (UnknownHostException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}}

93

A.1. ATUNES



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };



// Fetch arguments into a listList<String> arguments = StringUtils


// Start the Kernel, which really starts applicationKernel.startKernel(arguments);


}}



String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"), // ...intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };







}}

A.1.30 Atunes 1.09 TC04@FullSequencialModepublic class TC04 extends JunitETestCase {


String[] trace = new String[] {

94

A.1. ATUNES

exception("java.io.FileNotFoundException"),raiseSite("org.jaudiotagger.audio.AudioFile.checkFilePermissions"),intermediateSite("org.jaudiotagger.audio.mp3.MP3File.<init>"),intermediateSite("org.jaudiotagger.audio.mp3.MP3FileReader.read"),intermediateSite("org.jaudiotagger.audio.AudioFileIO.readFile"),intermediateSite("org.jaudiotagger.audio.AudioFileIO.read"),catchSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagDetector.getTags") };


new AudioFile("c:\\invalid.mp3");}


String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("org.jaudiotagger.audio.AudioFile.checkFilePermissions"),intermediateSite("org.jaudiotagger.audio.mp3.MP3File.<init>"),intermediateSite("org.jaudiotagger.audio.mp3.MP3FileReader.read"),intermediateSite("org.jaudiotagger.audio.AudioFileIO.readFile"),intermediateSite("org.jaudiotagger.audio.AudioFileIO.read"),catchSite("net.sourceforge.atunes.kernel.modules.repository.audio.AudioFile.readAudioProperties") };



}


@Testpublic void startup() {

String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("sun.net.www.http.HttpClient.<init>"),intermediateSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getImage"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getImage") };







}

A.1.32 Atunes 1.09 TC10@PartialSequencialMode/*** Precondition: Internet access.


95

A.1. ATUNES


method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.HttpURLConnection", methodParType = "..")


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getConnection"),catchSite("net.sourceforge.atunes.kernel.modules." +"audioscrobbler.AudioScrobblerService.getSimilarArtists") };



service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.youtube.com", 80, "teste", "1234"));




}}

A.1.33 Atunes 1.09 TC11@PartialSequencialMode/*** Steps: choose a name and press save.


@Test@FaultInjection(exception = "java.io.IOException", method = "net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture", methodReturnTypepublic void testTC11() {

String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture"),intermediateSite("net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.savePictureToFile"),intermediateSite("net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.exportPicture") };


try {AudioFile file = new AudioFile("./teste.mp3"); // Valid mp3 fileAudioFilePictureUtils.exportPicture(file);



}}

}


@Test@FaultInjection(exception = "java.net.MalformedURLException",method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "java.net.URL", methodParType = "java.lang.String")

96

A.1. ATUNES


String[] trace = new String[] {exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$3.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.DesktopHandler.openSearch"),

exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$2.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.DesktopHandler.openSearch"),



exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$5.getURL"),catchSite("net.sourceforge.atunes.kernel.handlers.DesktopHandler.openSearch") };


List<Search> list = SearchFactory.getSearches();for (Search search : list) {

DesktopHandler.getInstance().openSearch(search, "U2");}

}}



String[] trace = new String[] {exception("net.sourceforge.atunes.kernel.modules.audioscrobbler.submitter.SubmitterException"),raiseSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.submitter.Submitter.handshake"),intermediateSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.submitter.Submitter.submitTrackToLastFm"),intermediateSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.submitter.Submitter.submitTrack"),catchSite("br.cin.ufpe.exflow.atunes.test.TC13.startup") };




Kernel.startKernel(arguments);Submitter.setUser("teste");Submitter.setPassword("1234");

try {Submitter.setProxy(new Proxy(Type.HTTP, "www.google.com", 80,

"teste", "1234"));Submitter.submitTrack(new AudioFile("./teste.mp3"), 100);

} catch (SubmitterException e) {e.printStackTrace();

} catch (UnknownHostException e) {e.printStackTrace();


}

}}

97

A.1. ATUNES








service = new AudioScrobblerService(new Proxy(Type.HTTP,"www.invalid.inv", 80, "teste", "1234"));




}}



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),catchSite("net.sourceforge.atunes.kernel.handlers.AudioScrobblerServiceHandler.updateService") };




Kernel.startKernel(arguments);ProxyBean pb = new ProxyBean();AudioScrobblerServiceHandler.getInstance().updateService(pb, "", "");

try {Thread.sleep(20000); //Wait tester interaction w/ UI.

} catch (InterruptedException e) {e.printStackTrace();

}}

}


98

A.1. ATUNES


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),intermediateSite("net.sourceforge.atunes.kernel.modules.lyrics.LyricsEngine.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.modules.lyrics.LyrcEngine.getLyrics"),catchSite("net.sourceforge.atunes.kernel.modules.lyrics.LyrcEngine.getLyricsFor") };


List<String> arguments = StringUtils.fromStringArrayToList(new String[] { "" });

Kernel.startKernel(arguments);



}}

}

A.1.39 Atunes 1.09 TC17@PartialSequencialMode/*** Steps: Select a song from the playlist and add it as a favorite.



String[] trace = new String[] {exception("java.lang.NullPointerException"),raiseSite("net.sourceforge.atunes.kernel.handlers.FavoritesHandler.addFavoriteArtists"),catchSite("net.sourceforge.atunes.kernel.controllers.playList.PlayListListener.actionPerformed") };


// Fetch arguments into a listtry {


Kernel.startKernel(arguments);} catch (Exception e) {




}}

}

A.1.40 Atunes 1.10 TC11@PartialSequencialMode/*** Pre-condition: Internet access and weaving aspect ...TC01


99

A.1. ATUNES


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists") };


LastFmService lastFmService;try {

lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234");

lastFmService.getSimilarArtists("Bob");} catch (UnknownHostException e) {



}}

A.1.41 Atunes 1.10 TC02@PartialSequencialMode/*** Pre-condition: Internet access.


@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.new",methodReturnType = "", methodParType = "..")









}

}

A.1.42 Atunes 1.10 TC03@PartialSequencialMode/*** Precondition: Disable Internet connection.


100

A.1. ATUNES









}}



String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("org.jaudiotagger.audio.AudioFile.checkFilePermissions"),"org.jaudiotagger.audio.mp3.MP3File.<init>","org.jaudiotagger.audio.mp3.MP3FileReader.read","org.jaudiotagger.audio.AudioFileIO.readFile","org.jaudiotagger.audio.AudioFileIO.read",catchSite("net.sourceforge.atunes.kernel.modules.repository.tags.reader.TagDetector.getTags") };







}


101

A.1. ATUNES









}

A.1.45 Atunes 1.10 TC10@PartialSequencialMode/*** Pre-condition: Internet access.



method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.HttpURLConnection",methodParType = "..")


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getConnection"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists") };



lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234");




}}

A.1.46 Atunes 1.1 TC11@PartialSequencialMode/*** Precondition: turn off aspect 17. For this test does not cancel the popup.

102

A.1. ATUNES


@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture",methodReturnType = "void", methodParType = "..")







} catch (Throwable e) {e.printStackTrace();

}}

}


@Test@FaultInjection(exception = "java.net.MalformedURLException",method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "java.net.URL", methodParType = "java.lang.String")










}

103

A.1. ATUNES

}



method = "net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.getBufferedImage",methodReturnType = "java.awt.image.BufferedImage",methodParType = "..")







}}

}







lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.invalid.inv", 80, "teste", "1234"), "teste", "1234");




}}


104

A.1. ATUNES

public class TC15 extends JunitETestCase {

@Test@FaultInjection(exception = "java.io.IOException", method = "net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy", methodReturnType = "nepublic void testTC15() {

String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),catchSite("net.sourceforge.atunes.kernel.handlers.ContextInformationServiceHandler.updateService") };




Kernel.startKernel(arguments);ProxyBean pb = new ProxyBean();ContextInformationServiceHandler.getInstance()

.updateService(pb, "", "");



}}

}

A.1.51 Atunes 1.10 TC16@PartialSequencialMode/*** Precondition: enable aspect ..TC15.



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),intermediateSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyricsEngine.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyrcEngine.getLyrics"),catchSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyrcEngine.getLyricsFor") };






}}

}

A.1.52 Atunes 1.10 TC17@PartialSequencialMode/*** Steps: Select a music and add to favorites.

*/

105

A.1. ATUNES



String[] trace = new String[] {exception("java.lang.NullPointerException"),raiseSite("net.sourceforge.atunes.kernel.modules.favorites.FavoritesHandler.addFavoriteArtists"),catchSite("net.sourceforge.atunes.kernel.actions.SetPlayListSelectionAsFavoriteArtistAction.actionPerformed") };








}}

@Overridepublic boolean verifyResults() {

return !super.verifyResults();}

A.1.53 Atunes 1.12 TC01@PartialSequencialMode/*** Pre-condition: Internet access and weaving aspect ...TC01



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler.AudioScrobblerService.getSimilarArtists") };



lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234",Locale.US);




}}

A.1.54 Atunes 1.12 TC02@PartialSequencialMode/*** Precondition: Internet connection.

*/

106

A.1. ATUNES


@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.new",methodReturnType = "", methodParType = "..")









}}

A.1.55 Atunes 1.12 TC03@PartialSequencialMode/*** Precondition: Disable Internet connection.










}}

107

A.1. ATUNES










}

A.1.57 Atunes 1.12 TC07@PartialSequencialMode/*** Steps: Select a music and add to favorites.










}

108

A.1. ATUNES

A.1.58 Atunes 1.12 TC10@PartialSequencialMode//Requer conexeÃ§aÃ£o com a internet.public class TC10 extends JunitETestCase {


method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.HttpURLConnection",methodParType = "..")





lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234",Locale.US);




}}

A.1.59 Atunes 1.12 TC12@PartialSequencialMode/*** Precondition: turn off aspect 17. For this test does not cancel the popup.

**/public class TC11 extends JunitETestCase {

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.utils.PictureExporter.savePicture",methodReturnType = "void",methodParType = "..")

public void testTC11 {






} catch (Throwable e) {e.printStackTrace();

}}

109

A.1. ATUNES

}


@Test@FaultInjection(exception = "java.net.MalformedURLException",method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "java.net.URL",methodParType = "java.lang.String")










}}



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),intermediateSite("net.sourceforge.atunes.kernel.modules." +"contextInformation.lyrics.engines.LyricsEngine.getConnection"),

catchSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics." +"engines.LyricsDirectoryEngine.getLyricsFor") };




try {

110

A.1. ATUNES

Thread.sleep(20000); //Wait tester interaction w/ UI.} catch (InterruptedException e) {


}}




String[] trace = new String[] {exception("java.lang.NullPointerException"),raiseSite("net.sourceforge.atunes.kernel.handlers." +"FavoritesHandler.addFavoriteArtists"),

catchSite("net.sourceforge.atunes.kernel.actions." +"SetPlayListSelectionAsFavoriteArtistAction.actionPerformed") };








}}



}



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.audioscrobbler." +"AudioScrobblerService.getSimilarArtists") };



lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234",new Locale("en"), new LastFmCache());

111

A.1. ATUNES




}}

A.1.64 Atunes 1.13 TC02@PartialSequencialMode/*** Precondition: Reuquire internet access


@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.new",methodReturnType = "",methodParType = "..")


String[] trace = new String[] {exception("java.io.IOException"),raiseSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };


// Start time measurementTimer timer = new Timer();timer.start();





}}

A.1.65 Atunes 1.13 TC03@PartialSequencialMode/*** This test require turn off internet connection.



String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.readURL"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getAmazonAlbum") };


// Start time measurement

112

A.1. ATUNES

Timer timer = new Timer();timer.start();





}}










}




String[] trace = new String[] {exception("java.net.UnknownHostException"),raiseSite("java.net.PlainSocketImpl.connect"),intermediateSite("sun.net.www.http.HttpClient.<init>"),intermediateSite("sun.net.www.protocol.http.HttpURLConnection.getInputStream"),intermediateSite("net.sourceforge.atunes.utils.NetworkUtils.getImage"),catchSite("net.sourceforge.atunes.kernel.modules.amazon.AmazonService.getImage") };

113

A.1. ATUNES


// Start time measurementTimer timer = new Timer();timer.start();





}

A.1.68 Atunes 1.13 TC10@PartialSequencialMode//Requer conexeÃ§aÃ£o com a internet.public class TC10 extends JunitETestCase {

@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.kernel.modules.proxy.Proxy.getConnection",methodReturnType = "java.net.HttpURLConnection",methodParType = "..")





lastFmService = new LastFmService(new Proxy(Type.HTTP,"www.g1.com", 80, "teste", "1234"), "teste", "1234",new Locale("en"), new LastFmCache());




}}

A.1.69 Atunes 1.13 TC11@PartialSequencialMode/*** Para este teste nÃ£o cancelar o popup.


@Test@FaultInjection(exception = "java.io.IOException",method = "net.sourceforge.atunes.utils.AudioFilePictureUtils.savePictureToFile",methodReturnType = "void", methodParType = "..")public void testTC11() {


114

A.1. ATUNES

exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.utils.AudioFilePictureUtils.savePictureToFile"),intermediateSite("net.sourceforge.atunes.utils.AudioFilePictureUtils.exportPicture"),intermediateSite("br.cin.ufpe.exflow.atunes.test.TC11.startup") };





}}

}


@Test@FaultInjection(exception = "java.net.MalformedURLException",method = "net.sourceforge.atunes.model.search.Search.getURL",methodReturnType = "java.net.URL",methodParType = "java.lang.String")


String[] trace = new String[] {exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$3.getURL"),catchSite("net.sourceforge.atunes.kernel.modules.desktop.DesktopHandler.openSearch"),

exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$2.getURL"),catchSite("net.sourceforge.atunes.kernel.modules.desktop.DesktopHandler.openSearch"),



exception("java.net.MalformedURLException"),raiseSite("net.sourceforge.atunes.kernel.modules.internetsearch.SearchFactory$5.getURL"),catchSite("net.sourceforge.atunes.kernel.modules.desktop.DesktopHandler.openSearch") };




}}



String[] trace = new String[] {exception("java.lang.IllegalArgumentException"),

115

A.1. ATUNES

raiseSite("net.sourceforge.atunes.kernel.controllers.osd.OSDDialogController.showOSD"),intermediateSite("net.sourceforge.atunes.kernel.modules.visual.VisualHandler.showOSDDialog"),catchSite("net.sourceforge.atunes.kernel.modules.player.PlayerHandler.playCurrentAudioObject") };



.fromStringArrayToList(new String[] { "" });Kernel.startKernel(arguments);clearTestCaseLog();ApplicationState.getInstance().setShowOSD(true);

}}



String[] trace = new String[] {exception("java.io.IOException"),raiseSite("net.sourceforge.atunes.kernel.utils.NetworkUtils.getProxy"),intermediateSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyricsEngine.getConnection"),intermediateSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyrcEngine.getLyrics"),catchSite("net.sourceforge.atunes.kernel.modules.contextInformation.lyrics.LyrcEngine.getLyricsFor") };



Kernel.startKernel(arguments);}

}



method = "net.sourceforge.atunes.kernel.utils.AudioFilePictureUtils.getBufferedImage",methodReturnType = "java.awt.image.BufferedImage",methodParType = "..")







}}

}

116

A.2. JEDIT

A.2 jEdit

A.2.1 jEdit 4.0 TC01/***Requer aspÃ©cto


@Test@FaultInjection(exception = "bsh.ParseException",

method = "bsh.Interpreter.Line",methodReturnType = "boolean",methodParType = "")


exception("bsh.ParseException"), raiseSite("bsh.Interpreter.Line"),catchSite("bsh.Interpreter.eval"),exception("bsh.ParseException"),raiseSite("bsh.Interpreter.Line"),intermediateSite("bsh.Interpreter.eval") };


try {new Interpreter().eval(new Reader() {

@Overridepublic int read(char[] cbuf, int off, int len)

throws IOException {return 0;

}

@Overridepublic void close() throws IOException {}

}, new NameSpace("name"), "info");} catch (Exception e) {


}}

A.2.2 jEdit 4.0 TC02@PartialSequencialModepublic class TC02 extends JunitETestCase {


String[] trace = new String[] {exception("java.lang.NullPointerException"),raiseSite("org.gjt.sp.jedit.MiscUtilities.isURL"),intermediateSite("org.gjt.sp.jedit.io.VFSManager.getVFSForPath"),intermediateSite("org.gjt.sp.jedit.BeanShell._runScript") };


try {BeanShell._runScript(null, path, null, true);

} catch (Exception e) {e.printStackTrace();

}}

117

A.2. JEDIT



}



String[] trace = new String[] { exception("java.io.IOException"),intermediateSite("com.microstar.xml.XmlParser.popInput"),intermediateSite("com.microstar.xml.XmlParser.readCh"),intermediateSite("com.microstar.xml.XmlParser.skipWhitespace"),intermediateSite("com.microstar.xml.XmlParser.parseMisc"),catchSite("com.microstar.xml.XmlParser.parseDocument") };


jEdit.main(new String[] { "" });

try {PluginListHandler ph = new PluginListHandler(new PluginList(),

"path");ph.startDocument();


}}

}



String[] trace = new String[] {exception("java.lang.ArrayIndexOutOfBoundsException"),intermediateSite("bsh.ASCII_UCodeESC_CharStream.ReadByte"),intermediateSite("bsh.ASCII_UCodeESC_CharStream.readChar"),intermediateSite("bsh.ParserTokenManager.jjMoveNfa_0"),intermediateSite("bsh.ParserTokenManager.jjMoveStringLiteralDfa0_0"),intermediateSite("bsh.ParserTokenManager.getNextToken") };


try {ParserTokenManager token_source = new ParserTokenManager(

new ASCII_UCodeESC_CharStream(new Reader() {


throws IOException {// TODO Auto-generated method stubreturn 0;

}

@Overridepublic void close() throws IOException {

// TODO Auto-generated method stub

118

A.2. JEDIT

}}, 0, 0, 0));

token_source.getNextToken();} catch (Exception e) {


}


// Se o erro existir o teste nao deve passarreturn !super.verifyResults();

}}



String[] trace = new String[] { exception("bsh.EvalError"),raiseSite("bsh.Name.toClass"),intermediateSite("bsh.BSHAmbiguousName.toClass"),intermediateSite("bsh.BSHType.getType"),intermediateSite("bsh.BSHTypedVariableDeclaration.eval"),intermediateSite("bsh.Interpreter.eval"),intermediateSite("bsh.Interpreter.source"),catchSite("bsh.Interpreter.main") };


Interpreter.main(new String[] { "C:\\Jedit\\Jedit\\jedit-4-0-final\\bsh\\Interpreter.java" });

}}

A.2.6 jEdit 4.0 TC01/*** Teste requer aspÃ©cto

*/@PartialSequencialModepublic class TC06 extends JunitETestCase {

@Test@FaultInjection(exception = "bsh.TargetError", method = "bsh.Interpreter.eval",

methodReturnType = "Object",methodParType = "java.oi.Reader, bsh.NameSpace, String")


String[] trace = new String[] { exception("bsh.TargetError"),raiseSite("bsh.Interpreter.eval"),intermediateSite("bsh.Interpreter.source"),catchSite("bsh.Interpreter.main") };


Interpreter.main(new String[] { "C:/Jedit/Jedit/jedit-4-0-final/bsh/Interpreter.java" });

}}

119

A.2. JEDIT


@Testpublic void TC07() {

String[] trace = new String[] {exception("java.lang.ClassCastException"),raiseSite("bsh.BSHArrayInitializer.eval") };


bsh.BSHArrayInitializer jjtn000 = new bsh.BSHArrayInitializer(4);try {

jjtn000.jjtAddChild(new bsh.Node() {

@Overridepublic void jjtOpen() {}

@Overridepublic Node jjtGetParent() {

return null;}

@Overridepublic int jjtGetNumChildren() {

return 0;}

@Overridepublic Node jjtGetChild(int i) {

return null;}

@Overridepublic void jjtClose() {}

@Overridepublic void jjtSetParent(Node n) {}

@Overridepublic void jjtAddChild(Node n, int i) {}

}, 0);jjtn000.eval(TC07.class, 1, new CallStack(), new Interpreter());


}}



}



String[] trace = new String[] { exception("bsh.EvalError"),

120

A.2. JEDIT

raiseSite("bsh.SimpleNode.eval"),intermediateSite("bsh.SimpleNode.eval"),catchSite("br.cin.ufpe.exflow.atunes.test.TC08.startup") };


BSHArguments bsa = new BSHArguments(1);try {

bsa.eval(new CallStack(), new Interpreter());} catch (EvalError e) {


}}



String[] trace = new String[] {exception("java.lang.NoSuchFieldException"),raiseSite("java.lang.Class.getField"),catchSite("org.gjt.sp.jedit.gui.DefaultInputHandler.parseKeyStroke") };


DefaultInputHandler.parseKeyStroke("+Teste");}

}



String[] trace = new String[] {exception("java.lang.NumberFormatException"),raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),catchSite("org.gjt.sp.jedit.Mode.getProperty") };


try {jEdit.main(new String[] { "" });BeanShell.showEvaluateDialog(new View(jEdit

.getBuffer("./br/cin/ufpe/exflow/atunes/test/TC01.java"),"text"));


}}

}



121

A.2. JEDIT

String[] trace = new String[] { exception("bsh.EvalError"),raiseSite("bsh.Interpreter.eval"),catchSite("br.cin.ufpe.exflow.atunes.test.TC11.startup") };





}




}}


// No teste aparece popup, digitar o numero 1.


String[] trace = new String[] { exception("java.net.ConnectException"),raiseSite("java.net.PlainSocketImpl.socketConnect"),intermediateSite("java.net.PlainSocketImpl.doConnect"),intermediateSite("java.net.PlainSocketImpl.connectToAddress"),intermediateSite("java.net.PlainSocketImpl.connect"),intermediateSite("java.net.SocksSocketImpl.connect"),intermediateSite("java.net.Socket.connect"),catchSite("org.gjt.sp.jedit.jEdit.main") };


try {jEdit.main(new String[] { "" });


}}

}



String[] trace = new String[] {exception("java.io.FileNotFoundException"),raiseSite("java.io.FileInputStream.open"),intermediateSite("java.io.FileInputStream.<init>"),intermediateSite("java.io.FileReader.<init>"),intermediateSite("bsh.Interpreter.source"),catchSite("bsh.Interpreter.main") };

122

A.2. JEDIT


try {Interpreter.main(new String[] { "C:\\invalidFile.inv" });


}}

}



String[] trace = new String[] { exception("java.io.IOException"),raiseSite("sun.nio.cs.StreamDecoder.ensureOpen"),intermediateSite("sun.nio.cs.StreamDecoder.read"),intermediateSite("java.io.InputStreamReader.read"),catchSite("bsh.ASCII_UCodeESC_CharStream.FillBuff") };


try {jEdit.main(new String[] { "" });jEdit.getFontProperty("./invFile.v");


}}

}



String[] trace = new String[] {exception("java.lang.NumberFormatException"),raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),intermediateSite("java.lang.Integer.<init>"),catchSite("org.gjt.sp.jedit.Mode.getProperty") };


try {jEdit.main(new String[] { "" });clearTestCaseLog();jEdit.saveSettings();


}}

}

A.2.16 jEdit 4.1 TC01public class TC01 extends JunitETestCase {

@Test

123

A.2. JEDIT

@FaultInjection(exception = "bsh.ParseException",method = "bsh.Interpreter.Line",methodReturnType = "boolean",methodParType = "")


String[] trace = new String[] { exception("bsh.ParseException"),raiseSite("bsh.Interpreter.Line"),catchSite("bsh.Interpreter.eval"),exception("bsh.ParseException"),raiseSite("bsh.Interpreter.Line"),intermediateSite("bsh.Interpreter.eval"),catchSite("br.cin.ufpe.exflow.atunes.test.TC01.startup") };





}




}}

A.2.17 jEdit 4.1 TC02@PartialSequencialMode







}}

}


@Test

124

A.2. JEDIT








}}

}









}}

}



String[] trace = new String[] {exception("java.lang.ArrayIndexOutOfBoundsException"),intermediateSite("bsh.ASCII_UCodeESC_CharStream.ReadByte"),intermediateSite("bsh.ASCII_UCodeESC_CharStream.readChar"),intermediateSite("bsh.ParserTokenManager.jjMoveNfa_0"),intermediateSite("bsh.ParserTokenManager.jjMoveStringLiteralDfa0_0"),intermediateSite("bsh.ParserTokenManager.getNextToken") };


125

A.2. JEDIT

try {ParserTokenManager token_source = new ParserTokenManager(

new ASCII_UCodeESC_CharStream(new Reader() {


throws IOException {// TODO Auto-generated method stubreturn 0;

}

@Overridepublic void close() throws IOException {

// TODO Auto-generated method stub

}}, 0, 0, 0));

token_source.getNextToken();} catch (Exception e) {


}


// Se o erro existir o teste nao deve passarreturn !super.verifyResults();

}}



String[] trace = new String[] { exception("bsh.EvalError"),raiseSite("bsh.Name.toClass"),intermediateSite("bsh.BSHAmbiguousName.toClass"),intermediateSite("bsh.BSHType.getType"),intermediateSite("bsh.BSHTypedVariableDeclaration.eval"),catchSite("bsh.Interpreter.eval"), exception("bsh.EvalError"),raiseSite("bsh.Name.toClass"),intermediateSite("bsh.BSHAmbiguousName.toClass"),"bsh.BSHType.getType", "bsh.BSHTypedVariableDeclaration.eval","bsh.Interpreter.eval", "bsh.Interpreter.source",catchSite("bsh.Interpreter.main") };



}}


@Test@FaultInjection(exception = "bsh.TargetError",

method = "bsh.Interpreter.eval",methodReturnType = "Object",methodParType = "java.oi.Reader, bsh.NameSpace, String")

126

A.2. JEDIT

public void startup() {




}}



String[] trace = new String[] {exception("java.lang.ClassCastException"),raiseSite("bsh.BSHArrayInitializer.eval") };


bsh.BSHArrayInitializer jjtn000 = new bsh.BSHArrayInitializer(4);try {

jjtn000.jjtAddChild(new bsh.Node() {

public void jjtOpen() {}

public Node jjtGetParent() {return null;

}

public int jjtGetNumChildren() {return 0;

}

public Node jjtGetChild(int i) {return null;

}

public void jjtClose() {}

public void jjtSetParent(Node n) {}

public void jjtAddChild(Node n, int i) {}

}, 0);jjtn000.eval(TC07.class, 1, new CallStack(), new Interpreter());


}}



}

127

A.2. JEDIT



String[] trace = new String[] { exception("bsh.EvalError"),raiseSite("bsh.SimpleNode.eval"),intermediateSite("bsh.SimpleNode.eval"),catchSite("br.cin.ufpe.exflow.atunes.test.TC08.startup") };





}


return !super.verifyResults();};

}


@Testpublic void startup() {




}






.getBuffer("./br/cin/ufpe/exflow/atunes/test/TC01.java"),"text", false));

} catch (Exception e) {

128

A.2. JEDIT


}}








}




}}








}}

}

129

A.2. JEDIT







}}

}


// No teste quando aparece popup, digitar o numero 1.


String[] trace = new String[] { exception("java.io.IOException"),raiseSite("bsh.ASCII_UCodeESC_CharStream.FillBuff"),intermediateSite("bsh.ASCII_UCodeESC_CharStream.ReadByte"),catchSite("bsh.ParserTokenManager.getNextToken") };




}}

}





try {

130

A.2. JEDIT

jEdit.main(new String[] { "" });clearTestCaseLog();jEdit.saveSettings();


}}

}

A.2.32 jEdit 4.2 TC01public class TC01 extends JunitETestCase {









}


});} catch (Exception e) {


}}



String[] trace = new String[] {exception("java.lang.NullPointerException"),raiseSite("org.gjt.sp.jedit.MiscUtilities.isURL"),intermediateSite("org.gjt.sp.jedit.jEdit.getBuffer"),intermediateSite("org.gjt.sp.jedit.BeanShell._runScript"),intermediateSite("org.gjt.sp.jedit.BeanShell._runScript"),catchSite("br.cin.ufpe.exflow.atunes.test.TC02.startup") };


try {

131

A.2. JEDIT

BeanShell._runScript(null, path, null, true);} catch (Exception e) {


}



}



String[] trace = new String[] {exception("java.lang.ClassCastException"),raiseSite("org.gjt.sp.jedit.buffer.KillRing.propertiesChanged"),intermediateSite("org.gjt.sp.jedit.jEdit.propertiesChanged"),intermediateSite("org.gjt.sp.jedit.jEdit.main") };




}}



}






}}

132

A.2. JEDIT








}}






}







.getBuffer("./br/cin/ufpe/exflow/atunes/test/TC01.java"),new org.gjt.sp.jedit.View.ViewConfig()));


}

133

A.2. JEDIT

}}








}


}, new NameSpace(new BshClassManager(), "name space"), "info");} catch (Exception e) {


}}


// No teste ao aparecer popup, digitar o numero 1.






}}

}

134

A.2. JEDIT







}}

}







}}

}






135

A.2. JEDIT


}}

}










}


}, new NameSpace(new BshClassManager(), "name"), "info");} catch (Exception e) {


}}



String[] trace = new String[] { exception("java.lang.NullPointerException") };setExceptionPath(trace);



}}


136

A.2. JEDIT


}






}}








}}


// No teste ao aparecer popup, digitar o numero 1.


String[] trace = new String[] {exception("java.lang.NumberFormatException"),

137

A.2. JEDIT

raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),catchSite("org.gjt.sp.jedit.Mode.getProperty") };





}}

}

A.2.49 jEdit 4.3 TC11PartialSequencialModepublic class TC11 extends JunitETestCase {







}




}}




setConfigurationBeforeTest();

138

A.2. JEDIT



}}

}







}}

}







}}

}




139

A.2. JEDIT

exception("java.lang.NumberFormatException"),raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),intermediateSite("java.lang.Integer.<init>"),catchSite("org.gjt.sp.jedit.Mode.getProperty") };




}}

}

A.2.54 jEdit 4.3.2 TC01@PartialSequencialMode










}


}, new NameSpace(new BshClassManager(), "name"), "info");} catch (Exception e) {


}}

A.2.55 jEdit 4.3.2 TC01@PartialSequencialMode/****/


140

A.2. JEDIT


String[] trace = new String[] { exception("java.lang.NullPointerException") };setExceptionPath(trace);



}}



}

A.2.56 jEdit 4.3.2 TC05@PartialSequencialModepublic class TC05 extends JunitETestCase {





}}




public void startup() {




}

141

A.2. JEDIT

}



String[] trace = new String[] {exception("org.gjt.sp.jedit.bsh.EvalError"),raiseSite("org.gjt.sp.jedit.bsh.SimpleNode.eval"),intermediateSite("org.gjt.sp.jedit.bsh.SimpleNode.eval"), };





}}









}}

}





142

A.2. JEDIT




}




}}







}}

}







}

143

A.3. HEALTH WATCHER

}}







}}

}







}}

}

A.3 Health Watcher

A.3.1 Health Watcher 1-2 OO TC01public class TC01 extends JunitETestCase {



144

A.3. HEALTH WATCHER

exception("java.lang.RuntimeException"),catchSite("lib.concurrency.ConcurrencyManager.endExecution") };


new ConcurrencyManager().endExecution(new Object());}

}

A.3.2 Health Watcher 1-2 OO TC02@PartialSequencialModepublic class TC02 extends JunitETestCase {

/*** Require TC02FE.aj

*/


String[] trace = new String[] {exception("lib.exceptions.TransactionException"),raiseSite("lib.persistence.PersistenceMechanism.beginTransaction"),intermediateSite("healthwatcher.business.HealthWatcherFacadeInit.insertComplaint"),intermediateSite("healthwatcher.business.HealthWatcherFacade.insertComplaint") };


try {Complaint complaint = new AnimalComplaint("User",

"descricaoQueixa", "observacaoQueixa","[email protected]", new Employee("emp", "123",

"emp da silva"), 1, null, new Date(Calendar.getInstance().get(Calendar.DAY_OF_MONTH), Calendar.getInstance().get(Calendar.MONTH), Calendar.getInstance().get(Calendar.YEAR)), new Address("endSolicitante", "", "24000", "PE", "9999999","city", "..."), (short) 1, new Date("10", "10","2010"), "timbu", new Address("casadabarbie", "","24000", "PE", "9999991", "city", "..."));

HealthWatcherFacade facade = HealthWatcherFacade.getInstance();facade.insertComplaint(new Complaint() {});


}}

}



String[] trace = new String[] {exception("lib.exceptions.ObjectNotFoundException"),raiseSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.update"), };


try {ComplaintRepositoryRDB compRdb = new ComplaintRepositoryRDB(

(PersistenceMechanism) HealthWatcherFacade.getPm());compRdb.update(new Complaint() {});

} catch (RepositoryException e) {e.printStackTrace();

145

A.3. HEALTH WATCHER

} catch (ObjectNotFoundException e) {e.printStackTrace();

} catch (ObjectNotValidException e) {e.printStackTrace();

}}

}

A.3.4 Health Watcher 1-2 OO TC04@FullSequencialModepublic class TC04 extends JunitETestCase {

@Test@FaultInjection(exception = "lib.exceptions.PersistenceMechanismException",

method = "lib.persistence.PersistenceMechanism.getCommunicationChannel",methodParType = "",methodReturnType = "Object")



exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.insert") };


try {DiseaseTypeRepositoryRDB repo = new DiseaseTypeRepositoryRDB(

PersistenceMechanism.getInstance());repo.insert(new DiseaseType() {});

} catch (ObjectAlreadyInsertedException e) {e.printStackTrace();



} catch (PersistenceMechanismException e) {e.printStackTrace();

}}

}

A.3.5 Health Watcher 1-2 OO TC05@FullSequencialModepublic class TC05 extends JunitETestCase{

/*** Precondition - system offline

*/

@Testpublic void TC02(){

String[] trace = new String[]{exception("java.rmi.ConnectException"),raiseSite("sun.rmi.transport.tcp.TCPEndpoint.newSocket"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.createConnection"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.newConnection"),intermediateSite("sun.rmi.server.UnicastRef.newCall"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.rebind"),intermediateSite("java.rmi.Naming.rebind"),

146

A.3. HEALTH WATCHER

catchSite("healthwatcher.business.HealthWatcherFacade.<init>")};setExceptionPath(trace);

HealthWatcherFacade.main(new String[]{"teste"});

try {PersistenceMechanism.getInstance();} catch (PersistenceMechanismException e) {e.printStackTrace();}}}


/*** Precondition - Server running

*/


String[] trace = new String[] {exception("lib.exceptions.ObjectNotFoundException"),intermediateSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.update"),intermediateSite("healthwatcher.business.complaint.ComplaintRecord.update"),catchSite("healthwatcher.business.HealthWatcherFacadeInit.updateComplaint") };


Complaint complaint = null;

try {HealthWatcherFacade facade = HealthWatcherFacade.getInstance();facade.updateComplaint(complaint);

complaint = new AnimalComplaint("User", "descricaoQueixa","observacaoQueixa", "[email protected]",new Employee("emp", "123", "emp da silva"), 1, null,new Date(Calendar.getInstance().get(Calendar.DAY_OF_MONTH),

Calendar.getInstance().get(Calendar.MONTH),Calendar.getInstance().get(Calendar.YEAR)),

new Address("endSolicitante", "", "24000", "PE", "9999999","city", "..."), (short) 1, new Date("10", "10","2010"), "timbu", new Address("casadabarbie", "","24000", "PE", "9999991", "city", "..."));

} catch (Exception e1) {e1.printStackTrace();

}}

}



String[] trace = new String[] {exception("java.lang.StringIndexOutOfBoundsException"),

147

A.3. HEALTH WATCHER

raiseSite("java.lang.String.substring"),catchSite("lib.util.Date.stringToData"),exception("lib.exceptions.InvalidDateException"),raiseSite("lib.util.Date.stringToData"), };


try {Date.stringToData("09101990", Date.FORMATO1);

} catch (InvalidDateException e) {e.printStackTrace();

}

}}



String[] trace = new String[] {exception("java.lang.StringIndexOutOfBoundsException"),raiseSite("java.lang.String.substring"),catchSite("lib.util.Date.stringToData"),exception("lib.exceptions.InvalidDateException"),raiseSite("lib.util.Date.stringToData"), };




}}

}







}

}}

148

A.3. HEALTH WATCHER



String[] trace = new String[] {exception("java.lang.NumberFormatException"),raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),intermediateSite("java.lang.Integer.parseInt"),catchSite("lib.util.Schedule.<init>"),exception("lib.exceptions.InvalidDateException"),raiseSite("lib.util.Schedule.<init>"),catchSite("lib.util.Schedule.stringToHorario"),exception("lib.exceptions.InvalidDateException"),raiseSite("lib.util.Schedule.stringToHorario") };


try {System.out.println(Schedule.stringToHorario("100:00:00",

Schedule.FORMATO1).getHora());} catch (InvalidDateException e) {


}}


/*** Require TC02FE.aj

*/


String[] trace = new String[] {exception("lib.exceptions.TransactionException"),raiseSite("lib.persistence.PersistenceMechanism.beginTransaction"),intermediateSite("healthwatcher.business.HealthWatcherFacadeInit.getDiseaseTypeList"),intermediateSite("healthwatcher.business.HealthWatcherFacade.getDiseaseTypeList"),catchSite("br.cin.ufpe.test.TC11.testTC11") };


Complaint complaint = null;try {




HealthWatcherFacade facade = HealthWatcherFacade.getInstance();

facade.getDiseaseTypeList();} catch (InvalidDateException e) {

e.printStackTrace();} catch (ObjectNotFoundException e) {

149

A.3. HEALTH WATCHER

e.printStackTrace();} catch (RemoteException e) {

e.printStackTrace();} catch (PersistenceMechanismException e) {


e.printStackTrace();} catch (RepositoryException e) {

e.printStackTrace();} catch (TransactionException e) {


}}

A.3.12 Health Watcher 1-2 OO TC12FullSequencialModepublic class TC12 extends JunitETestCase {

/*** Precondition - Server not running.

*/


String[] trace = new String[] {exception("java.rmi.ConnectException"),raiseSite("sun.rmi.transport.tcp.TCPEndpoint.newSocket"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.createConnection"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.newConnection"),intermediateSite("sun.rmi.server.UnicastRef.newCall"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.lookup"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.lookup"),catchSite("healthwatcher.view.servlets.HWServlet.init") };


HWServlet servlet = new HWServlet();try {

servlet.init(new ServletConfig() {

public ServletContext getServletContext() {return null;

}

public Enumeration getInitParameterNames() {return new Enumeration<Object>() {

public boolean hasMoreElements() {return false;

}

public Object nextElement() {return new Object();

}};

}

public String getInitParameter(String arg0) {return "par";

}});

} catch (ServletException e) {e.printStackTrace();

}}

}

150

A.3. HEALTH WATCHER


/*** Aspect TC13FE.aj required

*/@Test@FaultInjection(exception = "lib.exceptions.PersistenceMechanismException",

method = "lib.persistence.PersistenceMechanism.getCommunicationChannel",methodParType = "", methodReturnType = "Object")


String[] trace = new String[] {exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.AddressRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.AddressRepositoryRDB.insert") };


try {AddressRepositoryRDB repo = new AddressRepositoryRDB(

PersistenceMechanism.getInstance());repo.insert(new Address());





}}

}



*/




String[] trace = new String[] {exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert") };


try {ComplaintRepositoryRDB repo = new ComplaintRepositoryRDB(

PersistenceMechanism.getInstance());repo.insert(new Complaint() {});

151

A.3. HEALTH WATCHER





}}

}





String[] trace = new String[] {exception("lib.exceptions.ObjectNotFoundException"),raiseSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.search"),raiseSite("br.cin.ufpe.test.TC15.testTC15") };



PersistenceMechanism.getInstance());repo.search(-1);




}}

}

A.3.16 Health Watcher 1-2 OO TC16PartialSequencialModepublic class TC16 extends JunitETestCase {

/*** RES - 1AO Passou

*/


String[] trace = new String[] {exception("org.aspectj.lang.SoftException"),intermediateSite("healthwatcher.view.servlets.ServletWebServer.doGet") };


ServletWebServer server = new ServletWebServer();try {

server.doGet(new HttpServletRequest() {

public Object getAttribute(String arg0) {return null;

152

A.3. HEALTH WATCHER

}

public String getCharacterEncoding() {return null;

}

public int getContentLength() {return 0;

}

public String getContentType() {return null;

}

public ServletInputStream getInputStream() throws IOException {return null;

}

public String getParameter(String arg0) {return null;

}

public Enumeration getParameterNames() {return null;

}

public String[] getParameterValues(String arg0) {return null;

}

public String getProtocol() {return null;

}

public BufferedReader getReader() throws IOException {return null;

}

public String getRealPath(String arg0) {return null;

}

public String getRemoteAddr() {return null;

}

public String getRemoteHost() {return null;

}

public String getScheme() {return null;

}

public String getServerName() {return null;

}

public int getServerPort() {return 0;

}

public String getAuthType() {return null;

}

public Cookie[] getCookies() {return null;

}

public long getDateHeader(String arg0) {return 0;

}

153

A.3. HEALTH WATCHER

public String getHeader(String arg0) {return null;

}

public Enumeration getHeaderNames() {return null;

}

public int getIntHeader(String arg0) {return 0;

}

public String getMethod() {return null;

}

public String getPathInfo() {return null;

}

public String getPathTranslated() {return null;

}

public String getQueryString() {return null;

}

public String getRemoteUser() {return null;

}

public String getRequestURI() {

return null;}

public String getRequestedSessionId() {return null;

}

public String getServletPath() {return null;

}

public HttpSession getSession(boolean arg0) {return null;

}

public boolean isRequestedSessionIdFromCookie() {return false;

}

public boolean isRequestedSessionIdFromUrl() {return false;

}

public boolean isRequestedSessionIdValid() {return false;

}}, new HttpServletResponse() {

public void setContentType(String arg0) {}public void setContentLength(int arg0) {}

public PrintWriter getWriter() throws IOException {return null;

}

public ServletOutputStream getOutputStream() throws IOException {return null;

}

154

A.3. HEALTH WATCHER


}

public void setStatus(int arg0, String arg1) {}

public void setStatus(int arg0) {}

public void setIntHeader(String arg0, int arg1) {}

public void setHeader(String arg0, String arg1) {}

public void setDateHeader(String arg0, long arg1) {}}

public void sendRedirect(String arg0) throws IOException {}

public void sendError(int arg0, String arg1) throws IOException {}

public void sendError(int arg0) throws IOException {}

public String encodeUrl(String arg0) {return null;

}

public String encodeRedirectUrl(String arg0) {return null;

}

public boolean containsHeader(String arg0) {return false;

}

public void addCookie(Cookie arg0) {}});

} catch (SoftException e) {System.out

.println("ORIGINAL EXCEPTION: " + e.getCause().toString());e.printStackTrace();


}}

}

A.3.17 Health Watcher 1-10 AO TC01@PartialSequencialModepublic class TC01 extends JunitETestCase {


String[] trace = new String[] {exception("java.lang.RuntimeException"),catchSite("lib.concurrency.ConcurrencyManager.endExecution") };


new ConcurrencyManager().endExecution(new Object());

}}


155

A.3. HEALTH WATCHER


/*** Requires weaving with aspect TC02FE.aj

*/

String[] trace = new String[] {exception("org.aspectj.lang.SoftException"),intermediateSite("healthwatcher.business.HealthWatcherFacade.insertComplaint"),catchSite("br.cin.ufpe.test.TC02.TC02") };


try {Complaint complaint = new AnimalComplaint("User",

"descricaoQueixa", "observacaoQueixa","[email protected]", new Employee("emp", "123",

"emp da silva"), 1, null, new Date(Calendar.getInstance().get(Calendar.DAY_OF_MONTH), Calendar.getInstance().get(Calendar.MONTH), Calendar.getInstance().get(Calendar.YEAR)), new Address("endSolicitante", "", "24000", "PE", "9999999","city", "..."), (short) 1, new Date("10", "10","2010"), "timbu", new Address("casadabarbie", "","24000", "PE", "9999991", "city", "..."));

HealthWatcherFacade facade = HealthWatcherFacade.getInstance();facade.insertComplaint(new Complaint() {});


}}

}



String[] trace = new String[] {exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.update_aroundBody0"),intermediateSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.update"),catchSite("br.cin.ufpe.test.TC03.TC03") };


try {ComplaintRepositoryRDB compRdb = new ComplaintRepositoryRDB(

PersistenceMechanism.getInstance());compRdb.update(new Complaint() {});


}}

}

A.3.20 Health Watcher 1-10 AO TC04@FullSequencialModepublic class TC04 extends JunitETestCase {

156

A.3. HEALTH WATCHER






exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.insert") };



PersistenceMechanism.getInstance());repo.insert(new DiseaseType() {});


}}

}


/*** Precondition - system offline.

*/


String[] trace = new String[] {exception("java.rmi.ConnectException"),raiseSite("sun.rmi.transport.tcp.TCPEndpoint.newSocket"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.createConnection"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.newConnection"),intermediateSite("sun.rmi.server.UnicastRef.newCall"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.rebind"),intermediateSite("java.rmi.Naming.rebind"),catchSite("healthwatcher.business.HealthWatcherFacade.<init>") };


HealthWatcherFacade.main(new String[] { "teste" });

try {PersistenceMechanism.getInstance();


}}

}

A.3.22 Health Watcher 1-10 AO TC06@PartialSequencialMode

157

A.3. HEALTH WATCHER


@Test@FaultInjection(exception = "lib.exceptions.TransactionException",

method = "lib.persistence.PersistenceMechanism.beginTransaction",methodParType = "",methodReturnType = "void")


exception("lib.exceptions.ObjectNotFoundException"),intermediateSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.update"),intermediateSite("healthwatcher.business.complaint.ComplaintRecord.update"),intermediateSite("healthwatcher.business.HealthWatcherFacade.updateComplaint") };






} catch (InvalidDateException e1) {e1.printStackTrace();

}

HealthWatcherFacade facade = HealthWatcherFacade.getInstance();try {

facade.updateComplaint(complaint);} catch (Exception e) {


}}







}}

}

158

A.3. HEALTH WATCHER







}}

}







}

}}



String[] trace = new String[] {exception("java.lang.NumberFormatException"),raiseSite("java.lang.NumberFormatException.forInputString"),intermediateSite("java.lang.Integer.parseInt"),intermediateSite("java.lang.Integer.parseInt"),catchSite("lib.util.Schedule.<init>"),exception("lib.exceptions.InvalidDateException"),raiseSite("lib.util.Schedule.<init>"),catchSite("lib.util.Schedule.stringToHorario"),exception("lib.exceptions.InvalidDateException"),

159

A.3. HEALTH WATCHER

raiseSite("lib.util.Schedule.stringToHorario") };setExceptionPath(trace);

try {System.out.println(Schedule.stringToHorario("100:00:00",

Schedule.FORMATO1).getHora());} catch (InvalidDateException e) {


}}



String[] trace = new String[] {exception("org.aspectj.lang.SoftException"),intermediateSite("healthwatcher.business.HealthWatcherFacade.getDiseaseTypeList"),catchSite("br.cin.ufpe.test.TC11.testTC11"),exception("lib.exceptions.TransactionException"),raiseSite("lib.persistence.IPersistenceMechanism.beginTransaction") };






HealthWatcherFacade facade = HealthWatcherFacade.getInstance();

facade.getDiseaseTypeList();} catch (Exception e) {


}}


/*** Precondition - Server not running.

*/


String[] trace = new String[] {exception("java.rmi.ConnectException"),raiseSite("sun.rmi.transport.tcp.TCPEndpoint.newSocket"),intermediateSite("sun.rmi.transport.tcp.TCPChannel.createConnection"),

160

A.3. HEALTH WATCHER

intermediateSite("sun.rmi.transport.tcp.TCPChannel.newConnection"),intermediateSite("sun.rmi.server.UnicastRef.newCall"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.lookup"),intermediateSite("sun.rmi.registry.RegistryImpl_Stub.lookup"),catchSite("healthwatcher.view.servlets.HWServlet.init") };


HWServlet servlet = new HWServlet();try {

servlet.init(new ServletConfig() {

public ServletContext getServletContext() {return null;

}

public Enumeration getInitParameterNames() {return new Enumeration<Object>() {

public boolean hasMoreElements() {return false;

}

public Object nextElement() {return new Object();

}};

}

public String getInitParameter(String arg0) {return "par";

}});

} catch (ServletException e) {e.printStackTrace();

}}

}






String[] trace = new String[] {exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.AddressRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.AddressRepositoryRDB.insert") };


try {AddressRepositoryRDB repo = new AddressRepositoryRDB(

PersistenceMechanism.getInstance());repo.insert(new Address());


161

A.3. HEALTH WATCHER




}}

}



** RES - ERRO CAMINHO





exception("lib.exceptions.PersistenceMechanismException"),raiseSite("lib.persistence.PersistenceMechanism.getCommunicationChannel"),catchSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert"),exception("lib.exceptions.RepositoryException"),raiseSite("healthwatcher.data.rdb.ComplaintRepositoryRDB.insert") };


try {ComplaintRepositoryRDB repo = new ComplaintRepositoryRDB(

PersistenceMechanism.getInstance());repo.insert(new Complaint() {});





}}

}





String[] trace = new String[] {exception("lib.exceptions.ObjectNotFoundException"),

162

A.3. HEALTH WATCHER

raiseSite("healthwatcher.data.rdb.DiseaseTypeRepositoryRDB.search"),raiseSite("br.cin.ufpe.test.TC15.testTC15") };



PersistenceMechanism.getInstance());repo.search(-1);




}}

}

A.3.32 Health Watcher 1-10 AO TC16PartialSequencialModepublic class TC16 extends JunitETestCase {

/*** RES - 1AO Passou

*/


String[] trace = new String[] {exception("org.aspectj.lang.SoftException"),intermediateSite("healthwatcher.view.servlets.ServletWebServer.doGet") };


ServletWebServer server = new ServletWebServer();try {

server.doGet(new HttpServletRequest() {

public Object getAttribute(String arg0) {return null;

}


}

public int getContentLength() {return 0;

}

public String getContentType() {return null;

}

public ServletInputStream getInputStream() throws IOException {return null;

}

public String getParameter(String arg0) {return null;

}

public Enumeration getParameterNames() {return null;

}

public String[] getParameterValues(String arg0) {return null;

}

163

A.3. HEALTH WATCHER

public String getProtocol() {return null;

}

public BufferedReader getReader() throws IOException {return null;

}

public String getRealPath(String arg0) {return null;

}

public String getRemoteAddr() {return null;

}

public String getRemoteHost() {return null;

}

public String getScheme() {return null;

}

public String getServerName() {return null;

}

public int getServerPort() {return 0;

}

public String getAuthType() {return null;

}

public Cookie[] getCookies() {return null;

}

public long getDateHeader(String arg0) {return 0;

}

public String getHeader(String arg0) {return null;

}

public Enumeration getHeaderNames() {return null;

}

public int getIntHeader(String arg0) {return 0;

}

public String getMethod() {return null;

}

public String getPathInfo() {return null;

}

public String getPathTranslated() {return null;

}

public String getQueryString() {return null;

}

164

A.3. HEALTH WATCHER

public String getRemoteUser() {return null;

}

public String getRequestURI() {

return null;}

public String getRequestedSessionId() {return null;

}

public String getServletPath() {return null;

}

public HttpSession getSession(boolean arg0) {return null;

}

public boolean isRequestedSessionIdFromCookie() {return false;

}

public boolean isRequestedSessionIdFromUrl() {return false;

}

public boolean isRequestedSessionIdValid() {return false;

}}, new HttpServletResponse() {

public void setContentType(String arg0) {}public void setContentLength(int arg0) {}

public PrintWriter getWriter() throws IOException {return null;

}

public ServletOutputStream getOutputStream() throws IOException {return null;

}


}

public void setStatus(int arg0, String arg1) {}

public void setStatus(int arg0) {}

public void setIntHeader(String arg0, int arg1) {}

public void setHeader(String arg0, String arg1) {}

public void setDateHeader(String arg0, long arg1) {}}

public void sendRedirect(String arg0) throws IOException {}

public void sendError(int arg0, String arg1) throws IOException {}

public void sendError(int arg0) throws IOException {}

public String encodeUrl(String arg0) {return null;

}

public String encodeRedirectUrl(String arg0) {return null;

}

165

A.3. HEALTH WATCHER

public boolean containsHeader(String arg0) {return false;

}

public void addCookie(Cookie arg0) {}});

} catch (SoftException e) {System.out

.println("ORIGINAL EXCEPTION: " + e.getCause().toString());e.printStackTrace();


}}

}

166

Dissertação de Mestrado - UFPE · Muitos dos problemas encontrados no uso do mecanismo de...

Documents

Transcript of Dissertação de Mestrado - UFPE · Muitos dos problemas encontrados no uso do mecanismo de...