Anderson Moreira

Let children be childish don't allow them access to TVs, video games and computers!
TESTES UNITRIOS COM JUNIT
Introduo
Teste de software o processo de executar um sistema de maneira controlada, a fim de revelar seus defeitos e avaliar sua qualidade. Um
teste unitrio consiste em testar unidades individuais de uma aplicao a fim de descobrir defeitos nas mesmas. O nvel de abstrao
destas unidades depende muito do tipo de sistema sendo desenvolvido. Segundo [Burnstein, 2003], o processo de teste unitrio deve
envolver as seguintes atividades: Planejamento, Especificao e Projeto dos casos de teste, Preparao do cdigo auxiliar e Execuo
propriamente dita.
Sistemas de software esto sujeitos constante evoluo, bem como as tecnologias sobre as quais eles so construdos. No entanto,
faltam mtodos e tcnicas apropriados para dar apoio evoluo desses sistemas. Os benefcios que podem ser obtidos com o uso de
conjuntos consistentes de testes automatizados durante a realizao de manuteno corretiva, adaptativa, preventiva e perfectiva so
dos mais diversos. Considera-se que um teste foi satisfeito quando a funcionalidade avaliada por ele corretamente implementada, o
que deve ocorrer logo aps a implementao do teste. Implementam-se os testes da lista de casos de testes at que a funcionalidade
almejada tenha sido obtida, ou seja, at que todos os testes que a avaliam tenham sido satisfeitos.
Tcnicas
Existem muitas maneiras de se testar um software. Mesmo assim, existem as tcnicas que sempre foram muito utilizadas em sistemas
desenvolvidos sobre linguagens estruturadas que ainda hoje tm grande valia para os sistemas orientados a objeto. Apesar de os
paradigmas de desenvolvimento ser completamente diferentes, o objetivo principal destas tcnicas continua a ser o mesmo, encontrar
falhas no software. Abaixo esto descritas algumas das tcnicas mais conhecidas.
Caixa-branca
Tambm chamada de teste estrutural ou orientada lgica, a tcnica de caixa-branca avalia o comportamento interno do componente de
software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de
condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados.
Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnologia que determinarem a construo do
componente de software, cabendo, portanto avaliao de mais aspectos que os citados anteriormente. O testador tem acesso ao cdigo
fonte da aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e componentes. Este tipo de teste desenvolvido
analisando o cdigo fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira,
todas as variaes relevantes originadas por estruturas de condies so testadas.
Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para desenvolvimento de classes de teste para testar
classes ou mtodos desenvolvidos em Java. Tambm se enquadram nessa tcnica testes manuais ou testes efetuados com apoio de
ferramentas para verificao de aderncia a boas prticas de codificao reconhecidas pelo mercado de software. A aderncia a padres
e boas prticas visa principalmente a diminuio da possibilidade de erros de codificao e a busca de utilizao de comandos que gerem
o melhor desempenho de execuo possvel. Apesar de muitos desenvolvedores alegarem que no h ganhos perceptveis com essa
tcnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser
executado milhares ou milhes de vezes em intervalos de tempo pequenos. na realidade de produo que a soma dos aparentes
pequenos tempos de execuo e consumo de memria de cada programa poder levar o software a deixar de atender aos objetivos
esperados. A tcnica de teste de caixa-branca recomendada para as fases de teste de unidade e teste de integrao, cuja
responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o cdigo fonte produzido.
Caixa-preta
Tambm chamada de teste funcional, orientado a dado ou orientado a entrada e sada, a tcnica de caixa-preta avalia o comportamento
externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada so fornecidos, o teste
executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Como detalhes de implementao no
so considerados, os casos de teste so todos derivados da especificao.
Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas as entradas possveis seriam testadas, mas na
DISCIPLINAS GUIAS PROJETOS MATERIAL AULA VDEOS NOTAS OPORTUNIDADES ESTANTE
ampla maioria dos casos isso impossvel. Outro problema que a especificao pode estar ambgua em relao ao sistema produzido, e
como resultado as entradas especificadas podem no ser as mesmas aceitas para o teste. Uma abordagem mais realista para o teste de
caixa-preta escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas
possveis que so processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a
qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possveis pode
gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificao do sistema, pode-se encontrar
um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propsito do sistema, mas casos possveis incluem inteiros
pares, inteiros mpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.
Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de integrao, teste de sistema e teste de aceitao. A aplicao de
tcnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situaes de teste). A aplicao combinada de outra tcnica
tcnica de particionamento de equivalncia (ou uso de classes de equivalncia) permite avaliar se a quantidade de casos de teste
produzida coerente. A partir das classes de equivalncia identificadas, o testador construir casos de teste que atuem nos limites
superiores e inferiores destas classes, de forma que um nmero mnimo de casos de teste permita a maior cobertura de teste possvel.
Uma abordagem no desenvolvimento do teste de caixa-preta o teste baseado na especificao, de forma que as funcionalidades so
testadas de acordo com os requisitos. Apesar de necessrio, esse tipo de teste insuficiente para identificar certos riscos num projeto de
software.
Regresso
Essa uma tcnica de teste aplicvel a uma nova verso de software ou necessidade de se executar um novo ciclo de teste durante o
processo de desenvolvimento. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram
aplicados nas verses ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas de teste de
acordo com o impacto de alteraes provocado pela nova verso ou ciclo de teste. Para efeito de aumento de produtividade e de
viabilidade dos testes, recomendada a utilizao de ferramentas de automao de teste, de forma que, sobre a nova verso ou ciclo de
teste, todos os testes anteriores possam ser executados novamente com maior agilidade.
Tcnicas no funcionais
Outras tcnicas de teste existem para testar aspectos no-funcionais do software, como por exemplo, de acordo com necessidades de
negcio ou restries tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que verificam a operao correta do sistema
em relao a sua especificao, as tcnicas no funcionais verificam a operao correta do sistema em relao a casos invlidos ou
inesperados de entrada. uma forma de testar a tolerncia e a robustez do software em lidar com o inesperado.
Uma delas o uso conjunto de teste de desempenho e teste de carga, que verifica se o software consegue processar grandes
quantidades de dados, e nas especificaes de tempo de processamento exigidas, o que determina a escalabilidade do software. O teste
de usabilidade necessrio para verificar se a interface de usurio fcil de aprender e utilizar. Entre verificaes cabveis esto a relao
da interface com conhecimento do usurio, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes
componentes. J o teste de confiabilidade usado para verificar se o software seguro em assegurar o sigilo dos dados armazenados e
processados. O teste de recuperao usado para verificar a robustez do software em retornar a um estado estvel de execuo aps
estar em um estado de falha.
Fases
Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo
de profissionais diferente da implementao. Essa prtica pode resultar na fase de teste ser usada para compensar atrasos do projeto,
comprometendo o tempo devotado ao teste. Outra prtica comear o teste no mesmo momento que o projeto, num processo contnuo
at o fim do projeto.
Em contrapartida, algumas prticas emergentes como a programao extrema e o desenvolvimento gil focam o modelo de
desenvolvimento orientado ao teste. Nesse processo, os testes de unidade so escritos primeiro, por engenheiros de software. Antes da
implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando incrementalmente em pores maiores dos
casos de teste. Os testes so mantidos junto com o resto do cdigo fonte do software, e geralmente tambm integra o processo de
construo do software.
Teste de unidade
Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se testam as menores unidades de software desenvolvidas
(pequenas partes ou unidades do sistema). O universo alvo desse tipo de teste so as subrotinas ou mesmo pequenos trechos de cdigo.
Assim, o objetivo o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente
do todo.
Teste de integrao
Na fase de teste de integrao, o objetivo encontrar falhas provenientes da integrao interna dos componentes de um sistema.
Geralmente os tipos de falhas encontradas so de transmisso de dados. Por exemplo, um componente A pode estar aguardando o
retorno de um valor X ao executar um mtodo do componente B; porm, B pode retornar um valor Y, gerando uma falha. No faz parte
do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integrao entre sistemas). Essas interfaces so testadas
na fase de teste de sistema, apesar de, a critrio do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema
estar plenamente construdo.
Teste de sistema
Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em
busca de falhas em relao aos objetivos originais. Os testes so executados em condies similares de ambiente, interfaces sistmicas
e massas de dados quelas que um usurio utilizar no seu dia-a-dia de manipulao do sistema. De acordo com a poltica de uma
organizao, podem ser utilizadas condies reais de ambiente, interfaces sistmicas e massas de dados.
Teste de aceitao
Geralmente, os testes de aceitao so realizados por um grupo restrito de usurios finais do sistema, que simulam operaes de rotina
do sistema de modo a verificar se seu comportamento est de acordo com o solicitado. Teste formal conduzido para determinar se um
sistema satisfaz ou no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou no o sistema. Validao de um
software pelo comprador, pelo usurio ou por terceira parte, com o uso de dados ou cenrios especificados ou reais. Pode incluir testes
funcionais, de configurao, de recuperao de falhas, de segurana e de desempenho.
Teste de operao
Nessa fase o teste conduzido pelos administradores do ambiente final em que o sistema ou software entrar em ambiente produtivo.
Vale ressaltar que essa fase aplicvel somente a sistemas de informao prprios de uma organizao, cujo acesso pode ser feito
interna ou externamente a essa organizao. Nessa fase de teste devem ser feitas simulaes para garantir que a entrada em produo
do sistema ser bem sucedida. Envolve testes de instalao, simulaes com cpia de segurana dos bancos de dados, etc.. Em alguns
casos um sistema entrar em produo para substituir outro e necessrio garantir que o novo sistema continuar garantindo o suporte
ao negcio.
Testes alfa e beta
Em casos especiais de processos de desenvolvimento de software sistemas operacionais, sistemas gerenciadores de bancos de dados e
outros softwares distribudos em escala nacional e internacional os testes requerem fases tambm especiais antes do produto ser
disponibilizado a todos os usurios.
O perodo entre o trmino do desenvolvimento e a entrega conhecido como fase alfa e os testes executados nesse perodo, como testes
alfa. PRESSMAN afirma que o teste alfa conduzido pelo cliente no ambiente do desenvolvedor, com este olhando sobre o ombro do
usurio e registrando erros e problemas de uso.
Completada a fase alfa de testes, so lanadas a grupos restritos de usurios, verses de teste do sistema denominadas verses beta. Ele
tambm um teste de aceitao voltado para softwares cuja distribuio atingir grande nmero de usurios de uma ou vrias empresas
compradoras. PRESSMAN afirma que o teste beta conduzido em uma ou mais instalaes do cliente, pelo usurio final do software.
Diferente do teste alfa, o desenvolvedor geralmente no est presente. Conseqentemente, o teste beta uma aplicao do software
num ambiente que no pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginrios) que so
encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problemas relatados
durante os testes beta, os engenheiros de software fazem modificaes e depois se preparam para liberar o produto de software para
toda a base de clientes.
A comunidade do teste de software usa o termo teste fama de forma sarcstica referindo-se aos produtos que so mal testados e so
entregues aos usurios finais para que estes encontrem os defeitos j em fase de produo.
Candidato a lanamento
Ultimamente, e principalmente na comunidade de software livre, comum utilizar o termo candidato a lanamento para indicar uma
verso que candidata a ser a verso final, em funo da quantidade de erros encontradas. Tais verses so um passo alm do teste
beta, sendo divulgadas para toda a comunidade.
TDD Test Driven Development (Desenvolvimento Guiado por
Testes)
O conceito de Desenvolvimento Guiado por Testes define que antes de criarmos um cdigo novo (classe), devemos escrever um teste
(classe de Test Case) para ele. Essa prtica traz vrios benefcios s equipes de desenvolvimento e inclusive estes testes sero usados
como mtrica em todo o tempo de vida do projeto. Veja na Figura 1 um modelo de como funciona o processo de testes unitrios dentro
de seu projeto.
Figura 1. Processo de testes unitrios dentro de seu projeto.
O que Testes Unitrios?
Imagine por exemplo, se um avio s fosse testado aps a concluso de sua construo, com certeza isso seria um verdadeiro desastre,
nesse ponto que a engenharia aeronutica uma boa referncia em processos de construes de projetos de software principalmente
em sistemas de misso crtica, pois durante a construo e montagem de um avio, todos os seus componentes so testados
isoladamente at a exausto, e depois cada etapa de integrao tambm devidamente testada e homologada.
O teste unitrio, de certa forma se baseia nessa idia, pois uma modalidade de testes que se concentra na verificao da menor
unidade do projeto de software. realizado o teste de uma unidade lgica, com uso de dados suficientes para se testar apenas lgica
da unidade em questo.
Em sistemas construdos com uso de linguagens orientadas a objetos, essa unidade pode ser identificada como um mtodo, uma classe
ou mesmo um objeto.
Temos alguns dos principais fatores que motivam o uso sistemtico da prtica de testes unitrios:
1. Previne contra o aparecimento de bugs oriundos de cdigos mal escritos.
2. Cdigo testado mais confivel.
3. Permite alteraes sem medo (coragem)
4. Testa situaes de sucesso e de falha.
5. Resulta em outras prticas XP como: Cdigo coletivo, refatorao, integrao contnua.
6. Serve como mtrica do projeto (teste == requisitos)
7. Gera e preserva um conhecimento sobre as regras de negcios do projeto.
Organizao dos testes e prticas XP
Abaixo na Figura 2, temos um diagrama que mostra a forma como as classes de testes ficam organizadas em um projeto codificado em
Java e a correlao com algumas prticas XP.
Figura 2. Organizao das classes de testes.
Quando fazer Teste Unitrio?
No incio
Primeiro projetar e escrever as classes de testes, depois as classes com regra de negcios.
Diariamente
sugerido que sejam rodados os testes vrias vezes ao dia ( fcil corrigir pequenos problemas do que corrigir um problemo somente
no final do projeto).
Quem faz Teste Unitrio?
Test Case (para cada classe)
Desenvolvedor (Projeta, escreve e roda).
Test Suite (Roda vrios Test Cases)
Coordenador e Desenvolvedor (Projeta, escreve e roda).
Vale lembrar que o Teste de aceitao (homologao) feito junto ao cliente.
Outra viso nova, interessante e muito polmica a aproximao da responsabilidade dos testes ao programador, o que em algumas
outras abordagens metodolgicas feito somente por equipes separadas, como por exemplo, uma equipe de teste/homologao.
Porm esse contexto base de qualquer metodologia gil, pois dessa forma, o prprio programador, ao criar e executar os testes
adquiri um controle maior e imediato na preveno e correo de bugs, contribuindo substancialmente para reduo do tempo de vida
de um projeto.
O que se deve testar?
Sempre ns ficamos em dvida sobre o que devemos testar em nossas classes, existem alguns macetes que podem nos ajudar a
descobrir quais e quantos testes devero ser escritos:
1. A principal regra para saber o que testar : Tenha criatividade para imaginar as possibilidades de testes.
2. Comece pelas mais simples e deixe os testes complexos para o final.
3. Use apenas dados suficientes (no teste 10 condies se trs forem suficientes)
4. No teste mtodos triviais, tipo get e set.
5. No caso de um mtodo set, s faa o teste caso haja validao de dados.
6. Achou um bug? No conserte sem antes escrever um teste que o pegue (se voc no o fizer, ele volta)!
O que JUnit?
JUnit um framework para teste de unidade usado por programadores que desenvolvem aplicaes em linguagem Java [Beck, 2003].
Casos de teste no JUnit so constitudos por um ou mais mtodos, sendo que estes podem estar agrupados em sutes de teste.
Ele Fornece uma completa API (conjunto de classes) para construir os testes e Aplicaes grficas e em modo console para executar os
testes criados.
@Test O JUnit somente necessita da annotation @Test para identificar um mtodo de teste. Ela recebe parmetros e 2 so realmente
incrveis:
expected este parmetro serve para testar Exception, somente necessrio informar na annotation qual Exception esperada e
pronto:
Ex: @Test(expected=IOException.class)
timeout este serve testar tempo de execuo do teste, onde o teste falha se demorar mais que o tempo informado:
Ex: @Test(timeout=2000)
Adicionalmente, as Annotations @Before(Antes de) e @After(Depois de) permitem especificar pr e ps condies comuns a todos os
casos de teste.
possvel ter quantos mtodos @Before e @After quiser
Mtodos @Before e @After so herdados das superclasses
Mtodos @Before das superclasses so executados antes dos mtodos @Before da subclasse
Mtodos @After das superclasses so executados depois
Objetivo: agrupar cdigo comum a vrios testes
Para criar uma suite de testes com JUnit4:
@RunWith(Suite.class) @SuiteClasses( { ClasseFuncionalidadeTeste.class, ClasseTeste.class}) public class TestAll { }
A classe suite s existe para receber a annotation e ser executada, no necessitando de nenhum mtodo.
Principais assertivas:
assertTrue(String errorMessage, boolean booleanExpression): Verifica se a expresso booleana verdadeira.
assertFalse(String errorMessage, boolean booleanExpression): verifica se a expresso booleana falsa.
assertEquals(String errorMessage, Object a, Object b): Verifica se o objeto a igual ao objeto b.
assertNull(String errorMessage, Object o): Verifica se o objeto nulo.
assertNotNull(String errorMessage, Object o): Verifica se o objeto no nulo.
assertNotSame(String errorMessage, Object a, Object b): Verifica se o objeto a no igual(semelhante) ao objeto b.
assertSame(String errorMessage, Object a, Object b): Verifica se o objeto a igual(semelhante) ao objeto b.
fail(String errorMessage): utilizado para falhar o teste de um mtodo propositalmente.
failNotEquals(String errorMessage, Object a, Object b): utilizado para falhar o teste de um mtodo propositalmente se o objeto a
no igual ao objeto b.
failNotSame(String errorMessage, Object a, Object b): utilizado para falhar o teste de um mtodo propositalmente se o objeto a
no igual(semelhante) ao objeto b.
Os principais motivos que favorecem o uso desse framework so:
1. JUnit pode verificar se cada unidade de cdigo funciona da forma esperada.
2. Facilita a criao, execuo automtica de testes e a apresentao dos resultados.
3. Orientado a Objeto
4. free e pode ser baixado em: www.junit.org
Como instalar?
Para usar o JUnit em sua mquina basta ter em mente essas duas idias:
1. Caso voc no tenha o JUnit instalado, faa o download do arquivo junit.jar em www.junit.org, aps inclua-o no classpath para
compilar e rodar os programas de teste.
2. Porm o JUnit j vem configurado nas verses recentes de IDEs como Eclipse, NetBeans, JBuilder, BlueJ e outros.
Planejando os testes
Metodologias geis como Extreme Programming, exigem organizao e disciplina, portanto sugerido que voc faa um bom
planejamento antes de sair por a escrevendo cdigo feito um doido.
A lista abaixo exemplifica bem como voc pode planejar e executar seus testes:
1. Defina uma lista de tarefas a implementar (o que testar).
2. Escreva uma classe (Test Case) e implemente um mtodo de teste para uma tarefa da lista.
3. Rode o JUnit e certifique-se que o teste falha.
4. Implemente o cdigo mais simples que rode o teste.
5. Refatore o cdigo para remover a duplicao de dados.
6. Caso necessrio, escreva mais um teste ou refine o existente.
7. Faa esses passos para toda a lista de tarefas.
Arquitetura das classes
Para uma melhor compreenso de como o JUnit funciona importante que entenda como suas classes esto organizadas dentro da API
do framework (ver Figura 3).
Figura 3. Classes do JUnit.
Como implementar
Veja um exemplo de como voc pode codificar em Java, classes de testes:
Crie uma classe junit.framework.Test para cada classe a ser testada:
import junit.Test;
class SuaClasseTest { }
Para cada mtodo a ser testado defina um mtodo public void test???() com a annotation @Test
SuaClasse: public int Soma (Object o ) { }
SuaClasseTest: @Test public void testSoma ()
Analisando o resultado
Quando os testes forem executados em modo grfico, Veja na Figura 4, que os mtodos testados podem apresentar os seguintes
resultados: verde para sucesso, roxo para falha e vermelho para exceo.
Figura 4. Resultados possveis da execuo dos testes.
Eclipse Criando classes de teste
Para exemplificar o uso do JUnit, usaremos o IDE Eclipse 3.5, que atualmente um dos melhores ambientes para desenvolvimento de
aplicaes Java e por ser um projeto totalmente free que j incorpora em sua instalao, vrias funcionalidades que aplicam prticas XP
como refatorao, testes unitrios e padres. Portanto, nesse caso, voc no precisar fazer o download do JUnit e instal-lo
separadamente, pois o mesmo j est embutido no Eclipse.
Definio de regras a serem seguidas por todos os
desenvolvedores com relao a testes unitrios.
Primeiro seleciona a classe a ser testada, click com boto direito em cima dela e selecione: New -> JUnit Test Case (ver Figura 5).
Figura 5. Criando um Test Case para uma determinada classe.
Ser aberta uma caixa de dialogo com o nome da classe de teste preenchido (sugesto que pode ser adotada em no projeto) defina o
diretrio a ser criada esta classe Test (ver Figura 6).
Figura 6. Configurando a Classe Teste.
Click em Next e nesta prxima tela defina os mtodos a serem testados e depois click em Finish (ver Figura 7) assim ser criado sua
respectiva classe de teste.
Figura 7. Selecionando os mtodos a serem testados.
Agora s implementar os testes especficos para cada mtodo selecionado (ver Figura 8).
Figura 8. Ainda falta implementar os testes para esta classe.
Para executar o teste primeiro instale o Plugin do EMMA (eclemma-1.4.2) no eclipse.
EMMA uma ferramenta open source usada para medir e gerar relatrios de cobertura de cdigo Java. E pode ser utilizada com o JUnit a
fim de melhorar a cobertura dos testes, o plugin EclEmma [EclEmma 2008] empregado para obter informaes sobre os trechos de
cdigo do framework JUnit que no so exercitados pelos testes, criados durante seu desenvolvimento. Pois, mesmo utilizando TDD, nem
toda a funcionalidade implementada tem cem por cento de cobertura. Caso um trecho de cdigo no exercitado pelos testes necessite
ser alterado, outros testes que exercitam esse trecho devem ser criados, assegurando que os efeitos colaterais introduzidos durantes as
alteraes sejam detectados.
A utilizao de testes automatizados desde o incio do desenvolvimento possibilita ao desenvolvedor cuidar atentamente de cada parte
inserida ou modificada no framework para que a funcionalidade original no seja alterada. As prticas TDD e refatorao possibilitam que
o desenvolvedor realize qualquer tipo de manuteno de forma mais segura. Adicionalmente, os testes criados tambm servem como
documentao do sistema [Beck 2002] [Demeyer et al. 2002].
Para instalar o Plugin no eclipse basta descompactar o arquivo eclemma-1.4.2.rar e copiar a pasta eclemma-1.4.2 para o diretrio
ROOT_ECLIPSE/dropins (ver Figura 9).
Figura 9. Instalando o Plugin do EMMA.
Depois s restartar o eclipse e clicar no atalho Coverage -> Coverage As -> JUnit Test (ver Figura 10).
Figura 10. Rodando os Testes.
Na Figura 11 voc visualiza os testes aps executados que no nosso caso no passaram, pois ainda no foram devidamente
implementados.
Figura 11. Resultado dos testes executados.
Java Code Coverage for Eclipse com EclEmma 1.4.3
EclEmma uma ferramenta livre de cobertura de cdigo Java para o Eclipse, sob a Eclipse Public License. Internamente baseado na
ferramenta EMMA.
Segundo o site Oficial do EclEmma http://www.eclemma.org, o EclEmma possui as seguintes caracteristicas:
Desenvolvimento rpido / ciclo de teste: Inicia a partir do Eclipse, como execues de teste JUnit que pode ser analisado diretamente
para a cobertura de cdigo.
Rica Anlise de cobertura: Resultados so imediatamente resumidos e destacados nos editores de cdigo fonte Java.
No-invasivos: EclEmma no requer modificar seus projetos ou realizar qualquer outra configurao.
EclEmma acrescenta um atalho na barra de ferramentas do Eclipse. Ele chamado de Coverage mode(modo de Cobertura) e funciona
exatamente como o Run existentes e modos de depurao. A modalidade de lanamento de cobertura pode ser ativado a partir do menu
Executar ou a barra de ferramentas:
Aps sua aplicao ou teste de unidade ser finalizado as informaes cobertura de cdigo automaticamente disponvel no Eclipse:
Sntese de Cobertura: A vista Cobertura listas resumos cobertura para seus projetos de Java, que permite drill-down para o nvel de
mtodo.
Fonte destacadas: O resultado de uma sesso de cobertura tambm diretamente visvel nos editores de cdigo Java. Um cdigo de
cores totalmente personalizvel destaca, em parte, e no linhas cobertas. Isso funciona para o seu prprio cdigo-fonte, bem como
para acompanhar a fonte de bibliotecas externas.
Anlise de suporte adicionais recursos para sua cobertura de teste:
Contadores diferentes: Selecione se instrues, linhas, blocos bsicos, mtodos ou tipos de carga deve ser resumido.
Sesses de cobertura mltipla: possvel alternar entre os dados de cobertura de vrias sesses.
Mesclar Sesses: Os vrios e diferentes testes devem ser considerados para a cobertura de sesses de anlise que podem ser
facilmente fundidos.
Enquanto EclEmma essencialmente concebido para a execuo de teste e anlise dentro do Eclipse, ele possui algumas caractersticas
de importao / exportao.
Cobertura de importao de dados: Um assistente permite importar arquivos *.ec.
Exportar relatrio de Cobertura: dados de cobertura pode ser exportado como um arquivo *.ec ou no formato XML ou HTML.
Easy Mock 2.5.1
EasyMock 2 uma biblioteca que fornece uma maneira fcil de utilizar Mock Objects para interfaces de dados. Objetos Mock simulam
partes do comportamento do cdigo de domnio, e so capazes de verificar se eles so usados como definido. Classes de domnio podem
ser testados de forma isolada, simulando seus colaboradores com Mock Objects. Escrever e manter Mock Objects frequentemente uma
tarefa tediosa, que podem introduzir erros. EasyMock 2 gera dinamicamente Mock Objects sem necessidade de escrev-los, e nenhum
cdigo gerado!
Benefcios
No necessrio escrever na mo classes de objetos fictcios.
Apia a refatorao segura usando Mock Objects: cdigo de teste no vai quebrar em tempo de execuo quando renomear
mtodos ou parmetros de mtodo reordenao
Suporta valores de retorno e excees.
Suporta a verificao da ordem de chamadas de mtodo, por um ou mais objetos Mock.
Desvantagens
EasyMock 2 s funciona com Java 2 verso 5.0 ou superior.
EasyMock por padro suporta a gerao de Mock Objects somente para interfaces. Para aqueles que gostariam de gerar objetos
fictcios para as aulas, h uma extenso disponvel na home page do EasyMock.
Instalao
Descompacte o arquivo easymock2.5.1.zip do EasyMock. Ele contm um diretrio easymock2.5.1. Adicione o arquivo JAR do EasyMock,
easymock.jar, a partir deste diretrio para o seu classpath.
Uso
A maioria das partes de um sistema de software no funciona isoladamente, mas sim colaborar com outras partes para comear seu
trabalho feito. Em muitos casos, no se preocupam com os colaboradores em testes unitrios, como ns confio estes colaboradores. Se
nos preocupamos com isso, Mock Objects nos ajudar a testar a unidade em teste em isolamento. Objetos Mock substituir os
colaboradores da unidade em teste.
Compartilhe:
Copyright 2014 - Anderson Moreira Contango Theme Powered by WordPress
Cancel
Share