UNIVERSIDADE FEDERAL DE CAMPINA GRANDE
CENTRO DE ENGENHARIA ELÉTRICA E INFORMÁTICA
UNIDADE ACADÊMICA DE SISTEMAS E COMPUTAÇÃO
RELATÓRIO DE ESTÁGIO
VALIDAÇÃO DE UMA TÉCNICA PARA GERAÇÃO
AUTOMÁTICA DE TESTES COM OBJETOS MOCK
RENATO MICELI COSTA RIBEIRO
Estagiário
DALTON DARIO SEREY GUERRERO
Orientador Acadêmico
SABRINA DE FIGUEIRÊDO SOUTO
Supervisora Técnica
Campina Grande – PB
Dezembro de 2009
VALIDAÇÃO DE UMA TÉCNICA PARA GERAÇÃO AUTOMÁTICA DE TESTES COM
OBJETOS MOCK
APROVADO EM _________________________________
BANCA EXAMINADORA
____________________________________________________________
Dalton Dario Serey Guerrero, Prof. DSc.
ORIENTADOR ACADÊMICO
____________________________________________________________
Joseana Macêdo Fechine, Prof. DSc.
MEMBRO DA BANCA
____________________________________________________________
Sabrina de Figueirêdo Souto, BSc.
MEMBRO DA BANCA
AGRADECIMENTOS
Agradeço inicialmente a Sabrina Souto, por ter me convidado a auxiliá-la
em seu mestrado, me oferecendo a oportunidade de participar desse estágio;
agradeço a Dalton Serey, pelas discussões frutíferas, mesmo em face das
dificuldades em encontrá-lo; agradeço também a Alexandro Soares, a Pryscilla
Dóra e a Cícero Alan Cruz, pelas boas sugestões quanto a conduzir este
trabalho; e, finalmente, agradeço a Joseana Fechine, pelos votos de sucesso
ao acreditar no êxito deste trabalho.
APRESENTAÇÃO
Como parte das exigências do curso de Ciência da Computação, da
Universidade Federal de Campina Grande, para cumprimento da disciplina de
Estágio Integrado, apresenta-se o relatório de estágio, que expõe as atividades
desenvolvidas por Renato Miceli Costa Ribeiro, ao curso do período 2009.2,
sob a orientação acadêmica de Dalton Dario Serey Guerrero e supervisão
técnica de Sabrina de Figueirêdo Souto. Esse estágio integrado objetivou
validar a técnica Automock de geração automática de testes com Objetos
Mock.
O estágio foi realizado no Laboratório de Sistemas Distribuídos (LSD),
localizado na Universidade Federal de Campina Grande (UFCG), bloco CO.
Esse ambiente foi bastante propício para a realização do estágio, visto que
dispunha de todo o aparato necessário para o desenvolvimento das atividades.
O conteúdo do relatório está distribuído conforme a seguinte descrição.
Seção 1 – Introdução.
Seção 2 – Ambiente de Estágio.
Seção 3 – Fundamentação Teórica e Tecnologias Utilizadas.
Seção 4 – Atividades do Estágio.
Seção 5 – Considerações Finais.
Referências Bibliográficas.
Apêndices.
Anexos.
4
5
RESUMO
Testar softwares é uma atividade muito importante. É através dela que os
testadores descobrem faltas no software, que poderiam causar falhas de
execução. Uma boa prática de testes sobre sistemas orientados a objeto
consiste em isolar as várias unidades de código do restante do sistema de
modo a diminuir a influência entre elas durante a execução dos testes. Para
isso, uma solução bastante empregada são os Objetos Mock; entretanto,
desenvolver testes com Objetos Mock é uma tarefa tediosa e complexa, além
de requerer que os testadores possuam profundo conhecimento do sistema e
de suas interações. Em seu mestrado, Sabrina Souto propôs uma técnica
chamada Automock, para geração automática de código Mock a partir de
testes pré-existentes. Este relatório apresenta as atividades desenvolvidas por
Renato Miceli ao longo de seu estágio, que objetivaram avaliar a técnica
Automock. Para isso, foram utilizados experimentos e questionários, além de
análises quantitativas. Este é um trabalho em andamento e deverá ser
concluído por Sabrina Souto ao final de seu mestrado.
6
ABSTRACT
Testing softwares is an important task. It is by means of it that testers find out
faults on softwares, which could lead to execution failures. A recommended
testing practice over object-oriented systems consists in isolating the many
units of code from the rest of the system, so to decrease the influence between
them during the tests' execution. A commonly employed solution for that are the
Mock Objects; developing tests with Mock Objects, however, is a tedious and
complex task, besides requiring testers to posess deep knowledge about the
system and its interactions. On her Masters Course, Sabrina Souto proposed a
technique called Automock, for the automatic generation of Mock code out of
previously existing tests. This report presents the activities developed by
Renato Miceli during his internship, which aimed help evaluating the technique
Automock. In order to do that, there have been used experiments and surveys,
as well as quantitative analysis. This is an on-going work and should be finished
by Sabrina Souto by the end of her Masters Course.
7
8
SUMÁRIO
Lista de Siglas e Abreviaturas …................................................................................................. 11
Lista de Quadros …..................................................................................................................... 12
Lista de Tabelas …....................................................................................................................... 13
1. Introdução …........................................................................................................................... 14
2. Ambiente de Estágio …........................................................................................................... 17
2.1. Orientador Acadêmico …................................................................................................ 19
2.2. Supervisora Técnica ….................................................................................................... 19
3. Fundamentação Teórica …..................................................................................................... 21
3.1. Linguagem de Programação Java …............................................................................... 22
3.2. Ambiente de Desenvolvimento Eclipse ......................................................................... 22
3.3. Testes de Software Automatizados ............................................................................... 23
3.4. Arcabouço JUnit ….......................................................................................................... 23
3.5. Classes Stub …................................................................................................................ 24
3.6. Objetos Mock ….............................................................................................................. 24
3.7. Arcabouço EasyMock ..................................................................................................... 25
4. Atividades Realizadas …..…..................................................................................................... 26
4.1. Revisão Bibliográfica ….................…............................................................................... 27
4.2. Escrita de Artigo …....….................…............................................................................... 29
4.3. Proposta de Plano de Estágio ......…............................................................................... 29
4.4. Documentação das Atividades .....…............................................................................... 30
4.5. Seleção de Casos de Teste …........…............................................................................... 31
4.6. Participar do LADC'09 …...............…............................................................................... 33
4.7. Geração de Testes com Colaboradores Stub ................................................................. 34
4.8. Execução de Experimentos …......................................................................................... 35
4.9. Avaliação Preliminar de Tempo de Execução ................................................................ 37
4.10. Montagem de Questionário …..................................................................................... 39
4.11. Avaliação Preliminar do Número de Linhas de Código …............................................. 40
5. Considerações Finais …...…..................................................................................................... 43
Referências Bibliográficas …....................................................................................................... 45
APÊNDICE A …............................................................................................................................. 50
APÊNDICE B …............................................................................................................................. 59
9
APÊNDICE C …............................................................................................................................. 62
APÊNDICE D …............................................................................................................................. 72
APÊNDICE E …............................................................................................................................. 75
ANEXO A ….................................................................................................................................. 81
ANEXO B ….................................................................................................................................. 84
ANEXO C ….................................................................................................................................. 87
10
LISTA DE SIGLAS E ABREVIATURAS
BD – Banco de Dados
CD-ROM – Compact Disc, Read-Only Memory
CUT – Class Under Test (Classe Sob Teste)
DSC – Departamento de Sistemas e Computação
HP – Hewlett-Packard
IDE – Integrated Development Environment
IEEE – Institute of Electrical and Electronics Engineers
LA-WASP – Latin American Workshop on Aspect-Oriented Software Development
LCD – Liquid Crystal Display (Visor de Cristal Líquido)
LSD – Laboratório de Sistemas Distribuídos
LSI – Laboratório de Sistemas de Informação
SAST – Workshop Brasileiro de Teste de Software Sistemático e Automatizado
SBSE – Simpósio Brasileiro de Engenharia de Software
TDD – Test-Driven Development (Desenvolvimento Orientado a Testes)
UFCG – Universidade Federal de Campina Grande
11
LISTA DE QUADROS
Quadro 1 – Classes de Teste e seus respectivos Sistemas …....................................... 36
12
LISTA DE TABELAS
Tabela 1: Tempos gastos por participante na execução dos experimentos ................. 37
Tabela 2: Tempos gastos pela ferramenta Automock para gerar código mock ........... 37
Tabela 3: Ganho em tempo por participante frente à geração automática de código
mock ............................................................................................................................. 38
Tabela 4: Média de ganhos em tempo para intervalos de confiança de 95% …........... 38
Tabela 5: Número de linhas de código dos testes gerados em experimento …............ 41
Tabela 6: Média do total de linhas de código e erros para intervalos de confiança de
95% …............................................................................................................................ 41
13
SEÇÃO I
INTRODUÇÃO
14
1. INTRODUÇÃO
A atividade de construção do conhecimento não está desassociada da
prática do saber. Quando ambas caminham unidas, fortalecem-se os
conceitos, adquire-se experiência, obtém-se proeficiência e autossuficiência.
Participar de um estágio integrado, pois, é ser presenteado com um diferencial.
Essa oportunidade única na vida escolar do jovem aprendiz visa apresentar
uma visão prática das teorias já conhecidas. É através dela que se vivencia o
dia-a-dia de quem corriqueiramente usa pra fins reais os conceitos meramente
teóricos de outrora. Para a formação de um profissional, ter sido estagiário lhe
dá uma bagagem de conhecimento teórico e prático, firmemente fixados, e que
devem lhe acompanhar durante toda a vida.
Seguindo essa filosofia, Renato Miceli participou durante o segundo
semestre de 2009 de um estágio integrado. Ele foi realizado no Laboratório de
Sistemas Distribuídos (LSD), bloco CO do Campus I da Universidade Federal
de Campina Grande (UFCG), durante o período escolar 2009.2, sob orientação
acadêmica de Dalton Dario Serey Guerrero e supervisão técnica de Sabrina de
Figueirêdo Souto. Este relatório visa apresentar de forma sucinta as atividades
desenvolvidas por Renato Miceli ao longo de seu estágio integrado.
O estágio integrado desenvolvido teve por objetivo validar a técnica
Automock para geração de testes com Objetos Mock (SOUTO, 2009). O foco
do estágio foi entender o trabalho proposto, pesquisar soluções de avaliação
para problemas similares, e empregar a solução mais adequada para avaliar o
Automock sobre o Automock.
Objetivo Geral: Validar a técnica e o protótipo de ferramenta Automock de
geração de testes com Objetos Mock.
15
Objetivos Específicos:
•
Entender o trabalho desenvolvido e proposto por Sabrina Souto, a partir
de leitura de documentação por ela produzida, palestras e discussões
interpessoais.
•
Pesquisar soluções similares, a fim de identificar melhores abordagens
para proceder com a avaliação do trabalho proposto.
•
Conduzir o trabalho de avaliação usando a abordagem mais adequada,
oriunda do trabalho de pesquisa, visando identificar a viabilidade, os
benefícios e limitações da técnica Automock.
O restante do relatório abordará com mais detalhes o ocorrido no
decorrer do estágio integrado, focando as causas que resultaram em
mudanças no andamento das atividades, embasadas por argumentos que
justificam as decisões tomadas.
16
SEÇÃO II
AMBIENTE DE ESTÁGIO
17
2. AMBIENTE DE ESTÁGIO
Como citado na seção 1, o estágio integrado foi conduzido no
Laboratório de Sistemas Distribuídos (LSD). Este é um laboratório pertencente
à Universidade Federal de Campina Grande (UFCG), no âmbito do
Departamento de Sistemas e Computação (DSC), localizado no bloco CO.
O grupo de pesquisa em sistemas distribuídos já vem de longas datas:
fundado em 1996, já passou por diversas mudanças em infraestrutura básica.
Sua localidade atual, inaugurada em 2004, dedica
toda uma construção
própria ao laboratório. Desde sua fundação, os esforços do grupo de pesquisa
estão direcionados para a área de sistemas distribuídos, com foco claro nas
sub-áreas de computação em grade, sistemas entre-pares, gerenciamento de
Ti orientado a negócios, sistemas de arquivo distribuídos e computação nas
nuvens.
No LSD foram desenvolvidas soluções conhecidas para ambientes
distribuídos. Dentre elas, pode-se citar o OurGrid, para compartilhamento de
recursos computacionais ociosos; o Commune, para comunicação segura e
confiável entre pares através de uma rede; e o BeeFS, um sistema de arquivos
distribuído
sobre
máquinas
desktop,
que
utiliza
da
capacidade
de
armazenamento disponível nelas para criar um grande diretório de arquivos.
Muitas outras soluções já foram ou estão em desenvolvimento no laboratório,
que conta com o suporte financeiro da gigante da informática Hewlett-Packard
(HP), especialmente por meio dos projetos OurGrid e Hybrid Clouds, este do
qual o estagiário é pesquisador e desenvolvedor atualmente. Mais informações
acerca do ambiente de estágio podem ser obtidas na seção “Ambiente de
Estágio” no Apêndice A.
O LSD possui infraestrutura própria e dispõe de salas climatizadas e
máquinas de última geração. São computadores de uso pessoal com mouse,
teclado e monitor LCD, rodando sistemas Unix/Linux e Windows e serviços
básicos associados. Toda essa infraestrutura de informática é apoiada por uma
equipe de suporte, disponível em horário comercial para quaisquer problemas
18
que haja. Assim, o laboratório satisfaz todos os requisitos necessários para ser
posto de trabalho permanente no decorrer do estágio integrado.
Acima de tudo, foi no LSD que se iniciou o desenvolvimento da técnica
Automock, no contexto do projeto AutoTest, coordenado por Dalton Serey.
Apesar do fim desse projeto, o laboratório ainda conserva as infraestrutura de
serviços montada para suportá-lo; assim sendo, esse é o local mais que
propício para a condução do estágio integrado.
Dalton Serey e Sabrina Souto são, respectivamente, o orientador
acadêmico e a supervisora técnica desse estágio integrado. Suas informações
pessoais e profissionais são descritas em sequência.
2.1. ORIENTADOR ACADÊMICO
•
Nome: Dalton Dario Serey Guerrero
•
Função: Professor Adjunto e Coordenador de Curso
•
Endereço Profissional:
Universidade Federal de Campina Grande (UFCG)
Centro de Engenharia Elétrica e Informática (CEEI)
Coordenação do Curso de Ciência da Computação (CCC)
Rua Aprígio Veloso, s/n, Bodocongó
CEP 58429-900
Campina Grande - PB, Brasil.
Telefone: +55 (83) 3310-1027
•
Endereço de Email Pessoal: [email protected]
•
Endereço de Email Profissional: [email protected]
2.2. SUPERVISORA TÉCNICA
•
Nome: Sabrina de Figueiredo Souto
•
Função: Mestranda
19
•
Endereço Profissional:
Universidade Federal de Campina Grande (UFCG)
Departamento de Sistemas e Computação (DSC)
Laboratório de Sistemas Distribuídos (LSD)
Rua Aprígio Veloso, 882 - Bloco CO
Bodocongó
CEP 58109-970
Campina Grande - PB, Brasil.
Telefone: +55 (83) 3310-1647
Fax: +55 (83) 3310-1498
•
Endereço de Email Pessoal: [email protected]
•
Endereço de Email Profissional: [email protected]
20
SEÇÃO III
FUNDAMENTAÇÃO
TEÓRICA
21
3. FUNDAMENTAÇÃO TEÓRICA
3.1. LINGUAGEM DE PROGRAMAÇÃO JAVA
A linguagem de programação Java (JAVA, 2009) é uma linguagem de
programação desenvolvida pela Sun Microsystems, Inc. em 1995 que mescla
conceitos dos paradigmas imperativo e orientado a objeto. Sua sintaxe deriva
majoritariamente das linguagens de programação C e C++, embora tenha um
modelo de objetos bem mais simples e menos facilidades de baixo nível. Foi
feita para rodar sobre a Máquina Virtual Java, por meio da interpretação de
bytecodes, gerados pela compilação de código-fonte.
Para a condução do estágio, foi necessário conhecimento aprofundado
sobre o paradigma de programação orientado a objeto e suas boas práticas de
projeto, bem como proeficiência na linguagem de programação Java. Essa foi a
linguagem utilizada durante todo o trabalho já desenvolvido até o momento,
inclusive sendo a linguagem usada para desenvolver o protótipo de ferramenta
Automock, os cenários de estudo do protótipo e os sistemas para
experimentação. Apesar de ser geral, a técnica Automock só foi implementada
em ambientes Java (SOUTO, 2009), tornando esse um requisito fundamental
para a atividade de estágio.
3.2. AMBIENTE DE DESENVOLVIMENTO ECLIPSE
Um dos mais usados ambientes de desenvolvimento de softwares para a
linguagem de programação Java, compreende uma IDE e um sistema de
gerenciamento de plug-ins (ECLIPSE, 2009). É o sistema de facto utilizado na
UFCG para desenvolvimento de aplicações Java.
No contexto do trabalho, essa ferramenta foi de suma importância, pois
foi através dela que o protótipo Automock e os casos de teste simples para
22
validação foram desenvolvidos (SOUTO, 2009). Esta ferramenta foi usada
durante todo o decorrer do estágio para realizar alterações sobre código Java,
além de ser tecnologia assistencial obrigatória para os estudos de caso e
execução dos experimentos.
3.3. TESTES DE SOFTWARE AUTOMATIZADOS
Dentre os maiores princípios da Engenharia de Software estão as
recomendadas boas práticas de teste. Testar software é uma técnica eficaz
para identificar defeitos em um software que podem ocasionar em falhas de
execução. É fato que um maior tempo empregado com atividades de
verificação e validação diminui consideravelmente o tempo demandado em
atividades de depuração, refatoramento e evolução do software.
Para facilitar as atividades de teste de software, inúmeras ferramentas
surgiram. Elas se propõem a automatizar o passo-a-passo executado para
estimular o software em busca de falhas. Ter se tornado uma tarefa bem
menos custosa em termos de tempo contribuiu para tornar o teste de software
cada vez mais popular na academia e no mercado.
3.4. ARCABOUÇO JUNIT
Dos maiores arcabouços para desenvolvimento de testes de unidade
automáticos em sistemas Java é o JUnit (JUNIT, 2009). Na sua atual versão
4.x, é o arcabouço dominante na academia e no mercado para compor testes
automatizados sobre softwares Java.
Foi com uso do JUnit que o protótipo Automock foi validado. Além disso,
os testes que devem ser fornecidos ao protótipo são testes escritos usando o
arcabouço JUnit. Assim, todos os testes estudados, alterados e construídos
durante o estágio integrado estavam ou foram escritos usando JUnit.
23
3.5. CLASSES STUB
O conceito de Classes Stub está intimamente ligado às bases do
paradigma de programação orientado a objeto. Classes Stub são classes que
simulam o comportamento de outras classes do sistema. Para isso, elas devem
respeitar o mesmo contrato e retornar respostas predefinidas para certos
estímulos fornecidos ao software. O comportamento esperado é definido
estaticamente no código da classe Stub.
Classes Stub são um dos meios para prover isolamento da CUT em
testes de unidade. No entanto, podem se multiplicar ao longo do ciclo de vida
do software, por não serem reutilizáveis.
3.6. OBJETOS MOCK
Como o conceito de Classes Stub, o conceito de Objetos Mock também
está intimamente ligado ao paradigma de programação orientado a objeto.
Objetos Mock servem ao mesmo propósito de classes Stub. Diferenciam-se
dessas por terem seu comportamento definido dinamicamente em código, no
corpo dos métodos de teste. No mais, Objetos Mock têm a capacidade de
auxiliar na decisão sobre a falha ou aceitação de um teste, checando a
sequência de expectativas que deveriam ter sido satisfeitas quanto a
chamadas sobre si.
Objetos Mock, bem como Classes Stub, podem tornar a execução do
teste mais rápida, por não executarem algoritmos complexos, além de isolar a
CUT do restante do ambiente de teste. Por outro lado, código mock é bem
custoso de se escrever, requer conhecimento profundo do testador sobre o
sistema em estudo, além de ser bastante suscetível a mudanças sutis no
código do sistema (pequenas alterações no código podem levar a descartar o
código mock). O trabalho proposto visa solucionar esse problema, através de
da técnica Automock (SOUTO, 2009).
24
Para construir Objetos Mock eficientemente, existe uma variedade de
arcabouços disponíveis para a linguagem Java, dentre os quais destaca-se o
EasyMock.
3.7. ARCABOUÇO EASYMOCK
O
EasyMock
(EASYMOCK,
2009)
é
um
dos
arcabouços
de
desenvolvimento de código mock mais utilizados dentre os disponíveis para a
linguagem de programação Java. Ele provê a construção de Objetos Mock para
interfaces
e
classes
Java,
registra
listas
de
expectativas
e
omite
completamente a existência de um objeto falso por debaixo do tipo provido pelo
objeto. É bastante recomendado para TDD, visto que seu modo único de
registro de expectativas o torna imune à maioria dos refatoramentos feitos a
códigos Java.
Esse arcabouço foi de suma importância para o trabalho de estágio,
visto que é com uso dele que o protótipo Automock gera código mock para
testes JUnit. Por isso, toda e qualquer atividade que envolvesse Objetos Mock
no decorrer desse trabalho necessariamente utilizou o arcabouço EasyMock,
para fins de comparação de resultados.
25
SEÇÃO IV
ATIVIDADES
REALIZADAS
26
4. Atividades Realizadas
Nessa seção são apresentadas as atividades realizadas no decorrer do
estágio.
Note-se
que
a
sequência
de
atividades
está
ordenada
cronologicamente, por questões de organização.
4.1. Revisão Bibliográfica
Antes de se proceder com o trabalho de avaliação do Automock, foi
necessária uma pesquisa bibliográfica inicial do estado-da-arte. O objetivo
dessa atividade foi de agregar conhecimento acerca de outras técnicas
utilizadas para realizar a avaliação proposta. Foi necessário entender
primeiramente o contexto em que se inseria o problema sob estudo, as
abordagens que já haviam sido empregadas para resolver tal problema, além
de novas abordagens que potencialmente poderiam ser empregadas, para
enfim propor uma metodologia adequada para encarar o problema. Assim,
essa atividade foi de suma importância para a condução do trabalho de
avaliação do Automock.
A revisão bibliográfica apresentou Tim Mackinnon como o criador do
conceito de Objetos Mock (MACKINNON, 2001). Seu intuito primário era de
auxiliar os desenvolvedores a escrever testes para objetos isolados, enquanto
seguiam o método Extreme Programming (BECK, 2000).
Também foi mostrado que outra abordagem isolar esses objetos são os
Stubs, que, mesmo que tenham os mesmos objetivos dos Objetos Mock, não
são o mesmo (FOWLER, 2007). De acordo com Meszaros, Stubs proveem
respostas predefinidas para as chamadas feitas durante um teste; se usados
fora do programado para o teste, é possível que responsam incorretamente
(MESZAROS, 2007). Por outro lado, Objetos Mock são dinamicamente préprogramados com expectativas; se usados fora do programado para o teste,
eles podem indicar explicitamente uma falha. Há ainda outras características
que os diferenciam: por exemplo, Objetos Mock geralmente contam o número
27
de vezes que cada operação é invocada, além de verificar os argumentos
fornecidos às operações e terem seus valores de retorno pré-estabelecidos.
Através dessa atividade pôde-se conhecer uma gama de arcabouços
dedicados a auxiliar testadores na construção de testes com Objetos Mock.
Dentre eles, pode-se listar o EasyMock (EASYMOCK, 2009) e o GoogleMock
(GOOGLEMOCK, 2009).
A revisão bibliográfica também revelou alguns trabalhos diretamente
relacionados ao Automock. O GenUTest, por exemplo, é uma ferramenta que
captura e registra interações entre os objetos durante a execução de
programas Java para gerar testes JUnit (PASTERNAK, 2009). Apesar de
aparentar ser bastante similar à técnica proposta, GenUTest depende de uma
versão funcional do software para executar, e gera testes de unidade para
todos as classes do sistema; o Automock, por outro lado, espera que o testador
indique um objeto-alvo e provenha algum teste que exercite esse objeto
(SOUTO, 2009). Ainda, pelo que consta, o GenUTest, até o presente momento,
parece não ter sido levado a público, dificultando o estudo dessa ferramenta
que tanto se assemelha ao Automock.
Outros trabalhos bem relacionados foram um protótipo de ferramenta
para geração de Objetos Mock usando uma combinação de execuções
concreta e simbólica de código .NET (TILLMANN, 2006), e uma proposta de
ferramenta para conversão automática de testes de sistema em uma coleção
de testes de unidade, a fim de apoiar a fatoração de testes (SAFF, 2005). Esse
último trabalho utiliza a técnica de instrumentação do código binário do
sistema, inclusive de todas as suas dependências (por exemplo, as bibliotecas
que usa), exceto da CUT. Apesar da similaridade à técnica Automock, nenhum
desses trabalhos parece abordar o problema da maneira proposta (SOUTO,
2009), o que aumenta seu trabalho em relevância e originalidade.
A partir dessa atividade foram geradas as seções 2 e 1 dos artigos para
o SAST'09 e o LA-WASP'09, respectivamente, que podem ser encontrados nos
apêndices C e D.
28
4.2. Escrita de Artigo
Dada a relevância e originalidade do trabalho de geração automática de
testes com Objetos Mock, o próximo passo foi documentar seu estágio atual no
formato de artigo científico. Embora tenha sido útil para treinar a prática da
escrita de documentos formais, o maior objetivo dessa atividade era de
apresentar à comunidade científica a abordagem a ser seguida para solucionar
o problema da escrita de testes com Objetos Mock.
O primeiro fruto dessa atividade foi o artigo escrito para o SAST'09 (vide
apêndice C). Por questões de imaturidade do trabalho, esse artigo acabou não
sendo submetido para a conferência a tempo. Entretanto, a partir dele foi
escrito o artigo para o LA-WASP'09 (vide apêndice D). Esse último trabalho foi
submetido ao evento e notificado como aceito. Ele foi defendido por Sabrina
Souto durante o evento, ocorrido em outubro de 2009 em Fortaleza. Foi
publicado em CD-ROM pela IEEE Computer Society, juntamente com os anais
do SBSE'09.
4.3. Defesa de Plano de Estágio
A ideia do estágio era de realizar a avaliação da técnica Automock por
meio de estudos de caso. Para isso, deveria-se averiguar o ganho promovido
pela técnica automatizada frente à construção manual de testes com Objetos
Mock. Assim, seriam selecionados testes já desenvolvidos para os sistemas
sob estudo, que seriam convertidos manualmente e automaticamente (com uso
do protótipo de ferramenta) em testes com Objetos Mock. Sobre esses testes
com e sem o uso de Objetos Mock seriam aplicadas métricas preestabelecidas:
tempo para geração, total de linhas de código, cobertura da execução, número
de detecções de erro, equivalência em semântica. O resultado dessas
métricas, por uso de diferença simples, geraria o ganho proporcionado pela
técnica sobre a construção manual de testes com Objetos Mock.
Os sistemas para estudo foram selecionados pela proximidade da
equipe de desenvolvimento. Esses sistemas eram o OurBackup, o Hidrogis e o
OurGrid. Desenvolvido no LSD nos anos de 2007 e 2008 sob orientação de
29
Dalton Serey, o OurBackup
(OLIVEIRA, 2008) é voltado para
o
compartilhamento de arquivos entre amigos, visando o becape cruzado; o
Hidrogis foi desenvolvido no Laboratório de Sistemas de Informação (LSI), na
UFCG; e o OurGrid (CIRNE, 2006), também desenvolvido no LSD, foca no
compartilhamento de poder computacional entre várias grades de máquinas
oportunistas. Todos os três sistemas possuem desenvolvedores próximos, o
que facilitaria o trabalho de avaliação do Automock.
O Plano de Estágio, que pode ser obtido no Apêndice A, foi defendido
por meio de uma apresentação, disponível no Apêndice B. Após apreciação do
trabalho frente à professora e à turma da disciplina de Estágio Integrado, foi
aprovado com a pontuação máxima.
4.4. Documentação das Atividades
Foi acordado com a supervisora técnica que todas as atividades
relevantes desenvolvidas durante o estágio seriam registradas. Para tanto, foi
criado um espaço em wiki no serviço Redmine (REDMINE, 2009), hospedado
nos servidores do LSD. As atividades passíveis de documentação são
primariamente as reuniões, sejam formais ou informais; o andamento das
atividades, sejam de cumprimento obrigatório da disciplina, sejam decorrentes
da condução do estágio integrado; quaisquer ideias que forem surgindo, que
possam de alguma forma contribuir para melhorar o trabalho. Assim, durante
todo o decorrer do estágio, foram postadas anotações que documentam
adequadamente as atividades desenvolvidas no âmbito do estágio integrado.
Além de tudo, também foram documentados os cronogramas de
trabalho, horários de presença no estágio e as atividades desenvolvidas
atualmente no âmbito do estágio, tanto do estagiário quanto de seu supervisor
técnico. Portanto, o wiki do Redmine tornou-se serviço primordial na boa
condução do estágio integrado; obteve status de serviço de centralização das
informações concernentes ao estágio, bem como serviço de comunicação
confiável público entre o estagiário e seu supervisor técnico.
30
4.5. Seleção de Casos de Teste
Para dar início à avaliação da técnica Automock, foi necessário
selecionar um sistema como ponto de partida para estudá-lo, entendê-lo e, por
fim, poder extrair uma suíte de testes que comporia o estudo de caso. O
primeiro sistema escolhido foi o OurBackup (OLIVEIRA, 2008). Esse sistema
se apresenta em duas versões: a Home, voltada para usuários doméstico, e a
Enterprise, direcionada a usuários corporativos. Visto que o estagiário havia
participado do desenvolvido da versão Enterprise do OurBackup e isso
implicaria em uma curva de aprendizado menos custosa, essa foi a escolha
inicial de sistema para estudo.
Após alguns estudos sobre o estado atual do sistema, constatou-se que
o OurBackup Enterprise não possuia testes adequados para compor a suíte do
estudo de caso. Apenas dois testes envolviam uma CUT e seus colaboradores;
entretanto, esses testes já possuíam respectivos com uso de mocks. Os
demais testes do sistema se encaixam em cinco categorias: ou são testes de
unidade, cuja CUT é testada na inexistência de colaboradores; ou são testes
de aceitação sobre um módulo servidor, cujo módulo cliente recebe os
estímulos de entrada e fornece as respostas de saída; ou são testes de
unidade com CUT e colaboradores, cujos colaboradores já são objetos mock;
ou são testes de unidade cuja CUT não está bem modularizada, lidando
diretamente com o ambiente (seja agregando responsabilidade ou usando
instâncias locais de seus colaboradores em seus métodos), quando isso
deveria ser feito por meio de colaboradores globais; ou são testes nãodeterminísticos (isto é, nem toda execução admitirá o mesmo comportamento
resultante), que envolvem a realização de operações não necessariamente
sequenciais (paralelas ou concorrentes) para atingir condições probabilísticas
sobre o estado do sistema. (como é a maioria dos sistema distribuídos, senão
todos). Além disso, testes adequados para a técnica Automock (chamados
testes “mockáveis”) não devem ser dependentes do tempo de execução, como
ocorre com alguns testes não-determinísticos, uma vez que a substituição de
colaboradores reais por Objetos Mock pode alterar o tempo de execução do
sistema sensivelmente (imagine colaboradores para acesso a BD ou conexões
31
remotas). Dado o uso inviável dos testes do OurBackup Enterprise, não houve
outra opção senão descartar o sistema.
O próximo sistema sob estudo foi o OurBackup Home. Após diversas
análises do sistema e de seus testes, constatou-se que ele apresentava as
mesmas deficiências do sistema OurBackup Enterprise. No entanto, sua suíte
de testes com Objetos Mock era bem maior. Foi identificado que em ambos os
softwares os testes de unidade cuja CUT interage com diversos colaboradores
(isto é, os testes focados pelo Automock) já fazem uso de Objetos Mock.
Considera-se, pois, sua suíte de testes como de boa qualidade para os
padrões atuais de teste de software.
Uma alternativa em todo caso seria construir testes para os sistemas
sob estudo. Isso requere conhecimento profundo sobre esses sistemas e os
relacionamentos estabelecidos entre os objetos em tempo de execução. O
tempo de aprendizado seria grande. Portanto, essa foi uma alternativa
descartada.
Outra alternativa consistia em converter os testes com código mock em
testes com colaboradores reais, para então proceder de maneira inversa. No
entanto, isso implicaria em realizar manualmente ou dispor de uma ferramenta
para tal; ambas as abordagens podem apresentar imperfeições e não garantir
equivalência semântica entre os testes original e alterado (vale salientar que
avaliar a validade de uma técnica de conversão de testes com código mock em
testes com colaboradores reais é da mesma ordem de complexidade de avaliar
a técnica Automock). Também requere conhecimento aprofundado do sistema
para saber que colaborador real faz o papel exato do Objeto Mock presente em
um teste, para questões de substituição. Ainda é um requisito conhecimento
acerca da gerência de configuração do sistema, que pode ser bastante
complexa, dada a complexidade dos sistemas sob estudo. Por fim, uma
limitação dessa abordagem foi de que nem sempre há colaboradores reais no
software que se comportem de maneira exata ao modo prescrito pelos Objetos
Mock; esse código mock pode realizar o comportamento errôneo (casos de
erro ou de alteração do software original), ou ainda servir pra injetar falhas
propositais no sistema, desviando do comportamento esperado para um
colaborador. Ainda, mesmo que haja colaboradores que se comportem à
32
maneira dos Objetos Mock, é bem provável que as operações que eles
realizem resultem em efeitos colaterais sobre o ambiente – que não era
previsto no teste com mocks – e assim causem a falha do teste. Se os
relacionamentos entre os colaboradores reais e o ambiente são complexas,
avaliar o impacto da substituição de colaboradores mock por colaboradores
reais é uma atividade bem custosa.
Uma terceira alternativa consistia em substituir os colaboradores mock
por Stubs; afinal, Stubs podem ser programados também para realizar
expectativas predefinidas, mas de modo estático no código. Assim, haveria um
conjunto de classes dedicadas somente a reproduzir esse comportamento
durante a execução do código: os Stubs. Eles proveem os mesmos ganhos
obtidos por meio de Objetos Mock, mas sem não-determinismo, sem efeitos
colaterais, nem requerendo conhecimento profundo sobre os relacionamentos
entre os objetos do sistema. E como são classes, podem gerar instâncias para
atuar como colaboradores reais da CUT, que podem posteriormente ser
substituídos por Objetos Mock, através da técnica Automock.
Dos três sistemas selecionados para estudo, dois deles – OurBackup e
OurGrid – não se encaixavam no modelo de testes adequado para uso pelo
Automock (os chamados testes “mockáveis”). Como ainda não havia sido
fornecido acesso ao sistema Hidrogis até o momento (algo que estaria sendo
providenciado pela supervisora técnica) e as atividades não poderiam parar,
essa última alternativa aparentava a mais viável e foi a próxima atividade
conduzida no âmbito do estágio.
4.6. Participar do LADC'09
Antes de dar prosseguimento às atividades normais do estágio, houve o
evento LADC. A participação como ouvinte foi de suma importância, pois
durante o Fórum Estudantil ocorrido nesse evento, a supervisora técnica
apresentou o estágio atual do seu trabalho de mestrado, assunto intimamente
ligado ao trabalho desenvolvido no estágio integrado. As sugestões e críticas
colhidas no decorrer da apresentação da supervisora técnica contribuíram de
maneira sucinta para o andamento do trabalho de estágio.
33
4.7. Geração de Testes com Colaboradores Stub
Essa atividade foi o passo natural no andamento do trabalho de estágio.
Foram selecionados onze (11) testes do sistema OurBackup Home que
utilizavam Objetos Mock em sua forma original, para proceder com a atividade.
Os colaboradores mock foram todos substituídos por classes Stub que se
comportam da mesma maneira que os Objetos Mock. Assim, a semântica do
teste estaria assegurada sem que fosse necessário muito conhecimento acerca
do sistema ou do relacionamento entre os objetos durante a execução, visto
que toda a listagem de expectativas dos Objetos Mock está disponível no corpo
dos métodos de teste.
No entanto, percebeu-se que os testes que já faziam uso de Objetos
Mock (aqueles onze testes selecionados) apresentavam cenários típicos de
execução de sistemas de informação: consultas em bancos de dados,
relacionamento simples entre objetos, colaboradores sem muita complexidade.
Virtualmente, os testes selecionados eram casos de uso de sistemas de
informação, que apresentam a característica já definida da “mockabilidade”.
Não havia sentido em utilizar testes sobre sistemas distribuídos se o foco maior
desses testes era a característica não-distribuída dos objetos em teste.
Além disso, os sistemas escolhidos para estudo (excluindo-se o
Hidrogis, com o qual não houve contato) todos são sistemas robustos e que
demandam tempo em gerência de configuração para terem seus testes
executados. Assim, o custo para realizar o estudo de caso sobre os sistemas
escolhidos acabou sendo muito alto frente aos benefícios que eles poderiam
proporcionar. O tempo requerido era tanto que podia exceder o tempo
dedicado a todo o estágio.
Por fim, a abordagem tomada para avaliação do Automock por meio de
estudo de caso não dispunha de variabilidade estatística que trouxesse
segurança aos resultados obtidos. Só havia um único testador manual (o
estagiário), os testes eram poucos e bem similares uns aos outros, além de
terem sido adulterados de sua forma original (seus colaboradores mock haviam
sido substituídos por colaboradores Stub).
34
A solução encontrada foi rever o plano de avaliação e redirecionar
esforços para abordagens mais efetivas. O plano de avaliação foi alterado para
o modelo de experimentação, com uso de participantes voluntários, que
contribuiriam para a variabilidade estatística; e de questionários, para a
fundamentação, embasamento e correlação dos resultados obtidos na
experimentação com os voluntários.
4.8. Execução de Experimentos
O novo modelo adotado para o plano de avaliação do Automock foi a
experimentação. Para esse modelo, um conjunto de participantes voluntários
seria selecionado para converter testes de unidade simples em testes que
usam Objetos Mock. Esses participantes foram selecionados por conhecimento
prévio do conceito de mocks, bem como experiência com programação Java
(JAVA, 2009) e proeficiência nos arcabouços JUnit (JUNIT, 2009) e EasyMock
(EASYMOCK, 2009), utilizados para criar testes com Objetos Mock. Dada a
proximidade, os participantes selecionados para o experimento foram
majoritariamente oriundos do LSD, o ambiente de estágio. No total, e contando
com o estagiário, foram onze (11) os participantes selecionados.
Para uso na experimentação, foram desenvolvidos três pequenos
sistemas de informação utilizando a linguagem de programação Java (JAVA,
2009), com pequenas funcionalidades, poucas classes e alguns testes com uso
de JUnit (JUNIT, 2009). O primeiro sistema, denominado Aluno, envolve o
registro de notas de alunos em uma caderneta, bem como cálculo de média e
de resultado (aprovação ou reprovação); o segundo sistema, denominado
Autenticação, registra usuários por meio do par (login, senha) e permite
identificar o usuário no sistema; e o terceiro sistema, denominado Pedido,
permite o cadastro de produtos e a criação de pedidos contendo vários desses
produtos. Todos os três sistemas envolvem de alguma forma o padrão DAO, de
modo que os alunos, os usuários e os produtos são todos persistidos em disco.
Mais informações acerca dos sistemas Aluno, Autenticação e Pedido podem
ser encontradas, respectivamente, nos anexos A, B e C.
35
O objetivo dos participantes foi de reescrever os testes fornecidos com
uso de Objetos Mock, de modo a isolar a CUT do restante dos colaboradores
reais do sistema (isto é, os colaboradores seriam mocks). Cada participante
recebeu exatamente 2 (dois) testes sobre um único sistema específico (exceto
o estagiário, que converteu todos os testes de todos os sistemas em testes
com Objetos Mock). Todos os testes com Objetos Mock foram desenvolvidos
com uso dos arcabouços JUnit (JUNIT, 2009) e EasyMock (EASYMOCK,
2009), através da IDE Eclipse (ECLIPSE, 2009). Os testes fornecidos e seus
respectivos sistemas estão descritos no Quadro 1.
Quadro 1 – Classes de Teste e seus respectivos Sistemas
Identificador
Classe de Teste
Sistema
T1
AdicionaLinhaTest
Pedido
T2
TotalFinalTest
Pedido
T3
LoginValidoTest
Autenticação
T4
LoginInvalidoTest
Autenticação
T5
TestAlunoAprovadoFinal
Aluno
T6
TestAunoReprovadoInfrequencia
Aluno
T7
TestAlunoAprovadoNota
Aluno
T8
TestAlunoReprovadoFinal
Aluno
T9
TestAlunoReprovadoNota
Aluno
T10
TestAlunoAprovadoInexistente
Aluno
A execução dos experimentos foi acompanhada pelo estagiário e pela
supervisora técnica, a fim de cronometrar o tempo necessário para concluir a
conversão de cada um dos testes fornecidos. Visto que essa atividade ainda
está sendo conduzida, alguns dos participantes ainda não executaram o
experimento, logo os tempos não puderam ser cronometrados. A Tabela 1
apresenta o estado atual da execução dos experimentos, discriminando os
tempos gastos por cada participante na conversão dos testes fornecidos em
testes com Objetos Mock. Note-se que, por questões de sigilo, os nomes dos
participantes no experimento não serão fornecidos; cada participante exceto o
estagiário será identificado por “Px”, para x ∈ {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}.
36
Tabela 1: Tempos gastos por participante na execução dos experimentos
Participante
P1
Teste
P2
P3
P4
P5
P6
P7
P8
P9
P10
Renato
T1 14min
70min
33min
T2 10min
10min
6min
T3
13min
**
5min
T4
37min
**
3min
T5
**
13min
7min
T6
**
3min
3min
T7
49min
**
3min
T8
11min
**
2min
T9
30min
24min
2min
T10
26min
11min
1min
Foi feita uma avaliação preliminar a partir dos resultados obtidos até o
estágio atual. A execução do restante dos experimentos e posterior avaliação
de seus resultados foi definido como trabalho futuro e deverá ser conduzido
pela supervisora técnica. Esses trabalhos incluem estudar o estado da arte na
análise de variação de valores numéricos, definir métricas para mensuração de
erro (ganhos ou perdas), para então aplicá-las e analisar os resultados obtidos.
4.9. Avaliação Preliminar de Tempo de Execução
Uma vez conduzido o experimento, foi necessário executar o protótipo
de ferramenta Automock para poder comparar o ganho obtido entre as
construções manual e automática de testes com Objetos Mock. A Tabela 2
apresenta os tempos de execução do Automock para cada testes dos sistemas
sob experimento.
Tabela 2: Tempos gastos pela ferramenta Automock para gerar código mock
Teste
T1
T2
T3 T4 T5
T6 T7 T8 T9 T10
Automock 189s 257s 74s 28s 17s 24s 17s 16s 17s 14s
Conhecidos ambos os tempos de geração manual e automática de
código mock, pôde-se obter resultados preliminares do ganho da abordagem
37
automática sobre a abordagem manual para construção de testes com Objetos
Mock. Esses resultados preliminares são apresentados na Tabela 3.
Tabela 3: Ganho em tempo por participante frente à geração automática de código mock
Participante
P1
Teste
P2
P3
P4
P5
P6
P7
P8
P9
P10
Renato
T1 651s
4011s
1791s
T2 343s
343s
103s
T3
706s
**
226s
T4
2192s
**
152s
T5
**
763s
403s
T6
**
156s
156s
T7
2923s
**
163s
T8
644s
**
104s
T9
1783s
1423s
103s
T10
1546s
646s
46s
A média dos ganhos para cada teste, bem como o erro aproximado
(considerando o ganho em tempo como sendo uma variável aleatória
normalmente distribuída) para um nível de confiança de 95% são apresentados
na Tabela 4.
Tabela 4: Média de ganhos em tempo para intervalos de confiança de 95%
Teste
Média
T1
T2
T3
2151s 263s 466s
T4
1172s
T5
T6
T7
583s 156s 1543s
Erro Aprox. 4245s 344s 3050s 12960s 2287s
0s
T8
T9
T10
374s 1103s 746s
17535s 3431s 2197s 1875s
A partir da Tabela 4, pode-se inferir que, assumindo o ganho em tempo
como normalmente distribuído, em todos os testes do experimento exceto o T6
há 95% de probabilidade de a média dos ganhos assumir valores negativos, o
que implica dizer que o uso do protótipo Automock pode proporcionar perdas
em tempo, ao invés de ganhos. No mais, os erros aproximados que definem
um intervalo de confiança de nível de 95% em torno da média foram muito
altos, o que indica falta de acurácia estatística. Para aumentar tal precisão,
seria necessária uma replicação dos experimentos para bem mais do que duas
ou três réplicas, como consta no estado atual do experimento.
38
Embora desses resultados seja possível inferir que o ganho promovido
pelo Automock pode ser de ordem de grandeza bem superior ao tempo de
execução automático para geração de código mock (observado ao confrontar
os dados das Tabelas 2 e 4), faz-se necessário estudos mais aprofundados
sobre as variáveis em estudo, especialmente quanto à distribuição de
probabilidade da variável aleatória que rege o ganho em tempo promovido pelo
uso da técnica Automock.
4.10. Montagem de Questionário
Algumas variáveis sob estudo no experimento não podem ser obtidas
diretamente da execução do experimento em si. Para isso, um questionário
pode auxiliar bastante, por conseguir extrair diretamente e claramente do
participante do experimento valores de variáveis que podem estar diretamente
relacionadas às variáveis sob estudo no próprio experimento. Assim facilita-se
o
trabalho
de
identificar
fatores
que
influenciem
positivamente
ou
negativamente certos aspectos-chave na avaliação da técnica proposta.
Dessa maneira, foi desenvolvido um questionário focando nos conceitos
necessários e suficientes para a condução do experimento (seu conteúdo pode
ser conferido no apêndice E). Ele foi dividido em 3 (três) subseções: a primeira,
denominada Conceitos Básicos, refere-se à fundamentação teórica necessária
para participar do experimento e tenta extrair quantitativamente estimativas do
tempo de experiência que cada participante possui com os conceitos e
ferramentas necessários para a condução do experimento; a segunda
subseção, denominada Realização do Experimento, objetiva receber um
retorno dos participantes quanto ao ocorrido durante a realização do
experimento, bem como suas percepções acerca do sistema experimentado,
suas classes e seus testes; e a terceira e última seção, denominada Avaliação
da Técnica, foca em extrair dos participantes do experimento se eles
compreenderam de fato a que se propõe a técnica Automock avaliada no
experimento, além de coletar novas motivações, desvantagens e limitações
não-identificadas previamente sobre a técnica proposta.
39
Esse questionário foi desenvolvido após algumas pesquisas sobre boas
práticas na construção de surveys, e ainda contou com a contribuição de
profissionais entendidos da área. Foram necessárias várias iterações de
desenvolvimento para evoluir o questionário ao seu formato atual.
Embora considere-se o questionário desenvolvido como ajustado para
ser enviado aos respondentes, essa atividade foi reservada como trabalho
futuro, visto o custo de realizá-la. Afinal, além de aguardar as respostas dos
participantes do experimento, é necessário realizar extensa pesquisa
bibliográfica acerca dos métodos existentes de análise de resultados em
questionários, e aplicar esses métodos nos resultados obtidos, visando
correlacionar os valores de resposta nos questionários entre si aos resultados
dos experimentos.
4.11. Avaliação Preliminar do Número de Linhas de Código
Embora a métrica sob estudo “tempo de execução” já tenha sido obtida
durante a execução dos experimentos, outras métricas só podem ser obtidas
posteriormente ao experimento. Dentre elas, pode-se citar “número de linhas
de código”, “cobertura da execução”, “número de erros descobertos” e
“equivalência em semântica”. Essa atividade foca a métrica “número de linhas
de código” sobre os testes com Objetos Mock obtidos ao final dos
experimentos. As demais métricas foram reservadas como trabalho futuro e
deverão ser estudadas pela supervisora técnica ao longo de seu mestrado.
Após pesquisas no estado-da-arte, constatou-se que uma ferramenta
adequada para extração do número de linhas de código (com discernimento de
linhas em branco e comentários) seria a ferramenta Metrics2 (METRICS2,
2009). Ela é uma evolução da ferramenta Metrics, que foi descontinuada
(METRICS, 2009). O objetivo de ambas as ferramentas é disponibilizar
facilmente
métricas
sobre
projetos
desenvolvidos
na
linguagem
de
programação Java (JAVA, 2009). Além do mais, a ferramenta dispõe plug-in
para a IDE Eclipse (ECLIPSE, 2009), o que facilitou a análise dos testes com
código mock, também desenvolvidos na plataforma Eclipse.
40
Na Tabela 5, é apresentado o número de linhas de código, ignorando
comentários e linhas em branco, dos testes com Objetos Mock gerados pelos
participantes do experimento. Note-se que esta é uma atividade em
andamento, cujos resultados ainda não foram plenamente apurados.
Tabela 5: Número de linhas de código dos testes gerados em experimento
Participante
P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 Renato
Teste
T1 58
**
102
T2 52
**
92
T3
18
**
38
T4
40
**
31
T5
**
23
43
T6
**
22
34
T7
34
**
38
T8
32
**
41
T9
39
31
38
T10
32
30
34
É possível inferir que, excetuando-se os testes do sistema Pedido, todas
as outras classes de teste com Objetos Mock possuem número total de linhas
de código próximos uns aos outros. Na Tabela 6, é apresentada a média do
total de linhas de código para cada teste em experimentação, bem como o erro
estimado para um nível de confiança de 95%, quando considerado que o total
de linhas de código é uma variável aleatória normalmente distribuída.
Tabela 6: Média do total de linhas de código e erros para intervalos de confiança de 95%
Teste
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
Média Aprox.
80
72
28
36
33
28
36
37
36
32
Desvio-Padrão Aprox.
31
28
14
6
14
34
3
6
4
2
Erro Aprox.
± 280 ± 254 ± 127 ± 57 ± 127 ± 76 ± 25 ± 57 ± 11 ± 5
Da Tabela 6 é possível inferir que quanto maior o número de amostras,
menor o erro que estabelece os limites superior e inferior do intervalo de
confiança de 95%. Os valores para maiores números de amostras possuem
menor desvio-padrão do que valores com menos amostras. Isso reforça
41
novamente a ideia de que é necessário uma maior replicação do experimento
para assegurar a validade estatística.
As análises desenvolvidas nessa atividade focaram somente no estudo
quantitativo do número total de linhas dos testes produzidos manualmente com
Objetos Mock. Diante da inacessibilidade dos códigos mock produzidos
automaticamente pela ferramenta Automock, o estudo comparativo entre as
duas abordagens foi elevado a trabalho futuro. Cabe aqui ainda realizar um
estudo qualitativo dos testes com Objetos Mock produzidos, de modo a
averiguar e tentar correlacionar as disparidades entre os números totais de
linhas dos testes produzidos por um e outro participantes do experimento.
42
SEÇÃO V
CONSIDERAÇÕES
FINAIS
43
5. Considerações Finais
A maior lição adquirida com esse trabalho, decerto, foi que planejamento
e antecipação nunca são demais. Sem dúvida a probabilidade de um trabalho
dar errado ou de ele estar seguindo por um caminho tortuoso diminui quanto
melhor ele for pensado, quanto mais detalhes forem postos à mesa, quanto
mais análise for feita sobre o problema de estudo, quanto mais conhecimento
for detido a respeito do estado-da-arte e, principalmente, quanto antes todo o
trabalho começar a ser desenvolvido: mais tempo vai ser poupado em caso de
falha, tempo que servirá com folga para refazer o caminho-solução para o
problema. Com toda certeza, planejamento e antecipação são as bases de
uma boa solução.
Ao final do estágio integrado, a visão sobre as atividades desenvolvidas
durante todo o semestre muda completamente. Certamente aumentou o
conhecimento sobre a dinâmica da condução de um trabalho de mestrado;
sobre o relacionamento entre orientador e orientando; sobre as facilidades e
dificuldades de se conduzir um trabalho científico, especificamente na área da
Engenharia de Software. Essa foi uma experiência única, com altos e baixos,
pressa e calma, que trouxe ganhos em conhecimento teórico e prático,
sobretudo relativo a relacionamento interpessoal. Porque homens não atingem
grandes feitos por si sós.
44
REFERÊNCIAS
BIBLIOGRÁFICAS
45
Referências Bibliográficas
ANT. Desenvolvido pela Apache Software Foundation, 2000-2009. Domínio da
Apache sobre a ferramenta Ant, para automatizar o processo de construção de
softwares. Disponível em: <http://ant.apache.org>. Acesso em: 13 dez. 2009.
ASPECTJ. Mantido pela The Eclipse Foundation, 2001-2009. Apresenta a
linguagem AspectJ que estende Java para o paradigma orientado a aspectos.
Disponível em: <http://www.eclipse.org/aspectj/>. Acesso em: 13 dez. 2009.
BECK, K. Extreme Programming Explained: Embrace Change. AddisonWesley, 2000.
BINDER, R. V. Testing Object-Oriented Systems: Models, Patterns, and
Tools. Addison-Wesley Professional, 2000.
CIRNE, W.; BRASILEIRO, F.; ANDRADE, N.; COSTA, L. B.; ANDRADE, A.;
NOVAES, R.; MOWBRAY, M. Labs of the World, Unite!!! Journal of Grid
Computing, Nova Iorque, v. 4, n. 3, p. 225-246, 2006.
ECLIPSE. Desenvolvido pela The Eclipse Foundation, 2001-2009. Apresenta a
suíte de desenvolvimento Eclipse, além de informações sobre manuseio.
Disponível em: <http://www.eclipse.org>. Acesso em: 13 dez. 2009.
EASYMOCK. Desenvolvido por Tammo Freese e Henri Tremblay, 2001-2009.
Apresenta o arcabouço EasyMock para desenvolvimento de código Mock.
Disponível em: <http://www.easymock.org>. Acesso em: 13 dez. 2009.
FOWLER,
M.
Mocks
Aren’t
Stubs,
02
jan.
2007.
Disponível
em:
<http://www.martinfowler.com/articles/mocksArentStubs.html>. Acesso em: 13
dez. 2009.
FREEMAN, S.; PRYCE, N.; MACKINNON, T.; WALNES, J. Mock roles, not
objects.
In:
Annual
ACM
SIGPLAN
Conference
on
Object-Oriented
Programming, Systems, Languages, and Applications (OOPSLA), 19., 2004,
Vancouver. Proceedings... Vancouver: ACM Press, 2004, p. 236-246.
46
GOOGLEMOCK.
Desenvolvido
pela
Google,
2009.
Domínio
dos
desenvolvedores do arcabouço GoogleMock para desenvolvimento de código
Mock. Disponível em: <http://code.google.com/p/googlemock/>. Acesso em: 13
dez. 2009.
JAVA. Desenvolvido pela Sun Microsystems, Inc., 1995-2009. Domínio da
desenvolvedora da plataforma Java. Disponível em: <http://www.java.com>.
Acesso em: 13 dez. 2009.
JUNIT. Mantido pelo time Object Mentor, 2000-2009. Apresenta o arcabouço
JUnit para desenvolvimento de testes em métodos ágeis. Disponível em:
<http://www.junit.org>. Acesso em: 13 dez. 2009.
KERIEVSKY, J. Point/Counterpoint: TDD: Don’t Muck It Up with Too Many
Mocks. Software, IEEE, v. 24, n. 3, p. 80-83, maio/jun. 2007.
KICZALES, G.; LAMPING, J.; MENDHEKAR, A.; MAEDA, C.; LOPES, C. V.;
LOINGTIER, J.M.; IRWIN, J. Aspect-Oriented Programming. In: EUROPEAN
CONFERENCE ON OBJECT-ORIENTED PROGRAMMING (ECOOP), 11.,
1997, Jyväskylä. Proceedings... Berlin: Springer-Verlag LNCS 1241, 1997,
v.1241, p. 220-242.
MACKINNON, T.; FREEMAN, S.; CRAIG, P. Endo-Testing: Unit Testing with
Mock Objects. In: SUCCI, G.; MARCHESI, M. eXtreme Programming
eXamined. Addison-Wesley, 2001, cap. 17, p. 287-301.
MACKAY, C. A. An Introduction To Mock Objects, 20 jun. 2007. Disponível
em: <http://www.colinmackay.net/tabid/159/Default.aspx>. Acesso em: 13 dez.
2009.
MESZAROS, G. xUnit Test Patterns: Refactoring Test Code. Pearson
Education, Inc., 2007.
METRICS. Hospedado no SourceForge, 2002-2005. Domínio da ferramenta de
geração de métricas sobre softwares escritos na linguagem Java. Disponível
em: <http://metrics.sourceforge.net/>. Acesso em: 15 dez. 2009.
47
METRICS2. Hospedado no SourceForge, 2009. Domínio da evolução da
ferramenta
de
geração
de
métrica
Metric.
Disponível
em:
<http://metrics2.sourceforge.net/>. Acesso em: 15 dez. 2009.
OLIVEIRA, M. I. S.; CIRNE, W.; BRASILEIRO, F.; GUERRERO, D. On the
Impact of the Data Redundancy Strategy on the Recoverability of Friend-toFriend Backup Systems. In: SIMPÓSIO BRASILEIRO DE REDES DE
COMPUTADORES E SISTEMAS DISTRIBUÍDOS (SBRC), 26., 2008, Rio de
Janeiro. Anais... Rio de Janeiro: Sociedade Brasileira de Computação, 2008.
PASTERNAK, B.; TYSZBEROWICZ, S.; YEHUDAI, A. GenUTest: a unit test
and mock aspect generation tool. International Journal on Software Tools
for Technology Transfer (STTT), Berlin/Heidelberg, v. 11, n. 4, p. 273-290,
set. 2009.
REDMINE. Mantido por Jean-Philippe Lang, 2006-2009. Apresenta o serviço
Redmine para auxílio no gerenciamento de projetos. Disponível em:
<http://www.redmine.org/>. Acesso em: 14 dez. 2009.
SAFF, D.; ARTZI, S.; PERKINS, J.; ERNST, M. D. Automatic test factoring for
Java.
In:
ANNUAL
INTERNATIONAL
IEEE/ACM
CONFERENCE
ON
AUTOMATED SOFTWARE ENGINEERING (ASE), 20., 2005, Long Beach.
Proceedings... Long Beach: IEEE Computer Society, 2005. p. 114-123.
SOUTO, S. F.; MICELI, R.; SEREY, D. Generating Mock-Based Test
Automatically. In: LATIN AMERICAN WORKSHOP ON ASPECT-ORIENTED
SOFTWARE DEVELOPMENT, 3., 2009, Fortaleza. Proceedings... Fortaleza:
IEEE Computer Society, 2009. 1 CD-ROM.
TILLMANN, N.; SCHULTE, W. Mock-object generation with behavior. In:
ANNUAL INTERNATIONAL IEEE/ACM CONFERENCE ON AUTOMATED
SOFTWARE ENGINEERING (ASE), 21., 2006, Tóquio. Proceedings... Tóquio:
IEEE Computer Society, 2006. p. 365-368.
48
APÊNDICES
49
APÊNDICE A – Plano de Estágio
50
APÊNDICE B – Apresentação da Defesa de Proposta de
Estágio
51
APÊNDICE C – Artigo para o SAST'09
52
APÊNDICE D – Publicação em Anais do LA-WASP'09
53
APÊNDICE E – Questionário de Avaliação de Perfil
54
ANEXOS
55
ANEXO A – Explicação sobre Sistema Aluno
56
ANEXO B – Explicação sobre Sistema Autenticação
57
ANEXO C – Explicação sobre Sistema Pedido
58