Bases de Dados Distribuidas

13/07/2015 Testes Unitários com JUnit | Anderson Moreira
Anderson Moreira
Let children be childish – don't allow them access to TVs, video games and computers!
Introdução
Teste de software é o processo de executar um sistema de maneira controlada, a fim de revelar seus defeitos e
avaliar sua qualidade. Um teste unitário consiste em testar unidades individuais de uma aplicação a fim de descobrir
defeitos nas mesmas. O nível de abstração destas unidades depende muito do tipo de sistema sendo desenvolvido.
Segundo [Burnstein, 2003], o processo de teste unitário deve envolver as seguintes atividades: Planejamento,
Especificação e Projeto dos casos de teste, Preparação do código auxiliar e Execução propriamente dita.
Sistemas de software estão sujeitos à constante evolução, bem como as tecnologias sobre as quais eles são
construídos. No entanto, faltam métodos e técnicas apropriados para dar apoio à evolução desses sistemas. Os
benefícios que podem ser obtidos com o uso de conjuntos consistentes de testes automatizados durante a
realização de manutenção corretiva, adaptativa, preventiva e perfectiva são dos mais diversos. Considerase que um
teste foi satisfeito quando a funcionalidade avaliada por ele é corretamente implementada, o que deve ocorrer logo
após a implementação do teste. Implementamse 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.
Técnicas
Existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito
utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os
sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento ser completamente diferentes, o
objetivo principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas
algumas das técnicas mais conhecidas.
Caixabranca
Também chamada de teste estrutural ou orientada à lógica, a técnica de caixabranca avalia o comportamento
interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de
software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de
caminhos lógicos, códigos nunca executados.
http://siep.ifpe.edu.br/anderson/blog/?page_id=976 1/20
Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a
construção do componente de software, cabendo, portanto avaliação de mais aspectos que os citados
anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação
de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de
teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações
relevantes originadas por estruturas de condições são testadas.
Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes
de teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes
manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação
reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da
possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor desempenho de
execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica
de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir
a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a
soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o
software a deixar de atender aos objetivos esperados. A técnica de teste de caixabranca é recomendada para as
fases de teste de unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do
software, que por sua vez conhecem bem o código fonte produzido.
Caixapreta
Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixapreta
avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do
mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado
esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são
todos derivados da especificação.
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis
seriam testadas, mas na ampla maioria dos casos isso é impossível. Outro problema é que a especificação pode
estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as
mesmas aceitas para o teste. Uma abordagem mais realista para o teste de caixapreta é escolher um subconjunto
de entradas que maximize a riqueza do teste. Podese agrupar subconjuntos de entradas possíveis que são
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 possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da
especificação do sistema, podese encontrar um subconjunto de inteiros que maximizem a qualidade do teste.
Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros
positivos, inteiros negativos, o maior inteiro, o menor inteiro.
Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema e teste de
aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações
de teste). A aplicação combinada de outra técnica – técnica de particionamento de equivalência (ou uso de classes
de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de
equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas
classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.
Uma abordagem no desenvolvimento do teste de caixapreta é o teste baseado na especificação, de forma que as
funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente
para identificar certos riscos num projeto de software.
Regressão
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo
ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a
cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Incluise
nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela
nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a
utilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os
testes anteriores possam ser executados novamente com maior agilidade.
Técnicas não funcionais
Outras técnicas de teste existem para testar aspectos nãofuncionais do software, como por exemplo, de acordo
com necessidades de negócio ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima,
que verificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam a
operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a
tolerância 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 especificações de tempo de processamento exigidas, o que
determina a escalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é
fácil de aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, 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 recuperação é usado para verificar a robustez do software em retornar a um estado estável
de execução após estar em um estado de falha.
Fases
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no
cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser
usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o
teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto.
Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o
modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro, por
engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito,
passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do
código fonte do software, e geralmente também integra o processo de construção do software.
Teste de unidade
Também conhecida como teste unitário ou teste de módulo, é 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 são as
subrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento
dentro de uma pequena parte do sistema funcionando independentemente do todo.
Teste de integração
Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de
um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente
A pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar
um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros
sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a
critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente
construído.
Teste de sistema
Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as
funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições
similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu diaa
dia de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais
de ambiente, interfaces sistêmicas e massas de dados.
Teste de aceitação
Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulam
operações 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 não seus critérios de aceitação e para permitir ao
cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por
terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de
configuração, de recuperação de falhas, de segurança e de desempenho.
Teste de operação
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 é aplicável somente a sistemas de informação próprios de uma
organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem
ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de
instalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará em
produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao
negócio.
Testes alfa e beta
Em casos especiais de processos de desenvolvimento de software – sistemas operacionais, sistemas gerenciadores
de bancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fases
também especiais antes do produto ser disponibilizado a todos os usuários.
O período entre o término do desenvolvimento e a entrega é conhecido como fase alfa e os testes executados nesse
período, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente do
desenvolvedor, com este “olhando sobre o ombro” do usuário e registrando erros e problemas de uso.
Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema
denominadas versões beta. Ele também é um teste de aceitação voltado para softwares cuja distribuição atingirá
grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é
conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o
desenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação do software num
ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou
imaginários) que são 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 modificações 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 sarcástica referindose aos produtos que são
mal testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de produção.
Candidato a lançamento
Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo candidato a lançamento
para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros encontradas. Tais
versões são um passo além 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 código novo (classe), devemos
escrever um teste (classe de Test Case) para ele. Essa prática traz vários benefícios às equipes de desenvolvimento
e inclusive estes testes serão usados como métrica em todo o tempo de vida do projeto. Veja na Figura 1 um modelo
de como funciona o processo de testes unitários dentro de seu projeto.
Figura 1. Processo de testes unitários dentro de seu projeto.
O que é Testes Unitários?
Imagine por exemplo, se um avião só fosse testado após a conclusão de sua construção, com certeza isso seria um
verdadeiro desastre, é nesse ponto que a engenharia aeronáutica é uma boa referência em processos de
construções de projetos de software principalmente em sistemas de missão crítica, pois durante a construção e
montagem de um avião, todos os seus componentes são testados isoladamente até a exaustão, e depois cada
etapa de integração também é devidamente testada e homologada.
O teste unitário, de certa forma se baseia nessa idéia, pois é uma modalidade de testes que se concentra na
verificação da menor unidade do projeto de software. É realizado o teste de uma unidade lógica, com uso de dados
suficientes para se testar apenas à lógica da unidade em questão.
Em sistemas construídos com uso de linguagens orientadas a objetos, essa unidade pode ser identificada como um
método, uma classe ou mesmo um objeto.
Temos alguns dos principais fatores que motivam o uso sistemático da prática de testes unitários:
1. Previne contra o aparecimento de “bugs” oriundos de códigos mal escritos.
2. Código testado é mais confiável.
3. Permite alterações sem medo (coragem)
4. Testa situações de sucesso e de falha.
5. Resulta em outras práticas XP como: Código coletivo, refatoração, integração contínua.
6. Serve como métrica do projeto (teste == requisitos)
7. Gera e preserva um “conhecimento” sobre as regras de negócios do projeto.
Organização dos testes e práticas 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 correlação com algumas práticas XP.
Figura 2. Organização das classes de testes.
Quando fazer Teste Unitário?
No início
Primeiro projetar e escrever as classes de testes, depois as classes com regra de negócios.
Diariamente
É sugerido que sejam rodados os testes várias vezes ao dia (é fácil corrigir pequenos problemas do que corrigir um
“problemão” somente no final do projeto).
Quem faz Teste Unitário?
Test Case (para cada classe)
Desenvolvedor (Projeta, escreve e roda).
Test Suite (Roda vários Test Cases)
Coordenador e Desenvolvedor (Projeta, escreve e roda).
Vale lembrar que o Teste de aceitação (homologação) é feito junto ao cliente.
Outra visão nova, interessante e muito polêmica é a aproximação da responsabilidade dos testes ao programador, o
que em algumas outras abordagens metodológicas é feito somente por equipes separadas, como por exemplo, uma
equipe de teste/homologação.
Porém esse contexto é à base de qualquer metodologia ágil, pois dessa forma, o próprio programador, ao criar e
executar os testes adquiri um controle maior e imediato na prevenção e correção de bugs, contribuindo
substancialmente para redução do tempo de vida de um projeto.
O que se deve testar?
Sempre nós ficamos em dúvida sobre o que devemos testar em nossas classes, existem alguns macetes que podem
nos ajudar a descobrir quais e quantos testes deverão 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 (não teste 10 condições se três forem suficientes)
4. Não teste métodos triviais, tipo get e set.
5. No caso de um método set, só faça o teste caso haja validação de dados.
6. Achou um bug? Não conserte sem antes escrever um teste que o pegue (se você não o fizer, ele volta)!
O que é JUnit?
JUnit é um framework para teste de unidade usado por programadores que desenvolvem aplicações em linguagem
Java [Beck, 2003]. Casos de teste no JUnit são constituídos por um ou mais métodos, sendo que estes podem estar
agrupados em suítes de teste.
Ele Fornece uma completa API (conjunto de classes) para construir os testes e Aplicações gráficas e em modo
console para executar os testes criados.
@Test – O JUnit somente necessita da annotation @Test para identificar um método de teste. Ela recebe
parâmetros e 2 são realmente incríveis:
expected – este parâmetro serve para testar Exception, somente é necessário informar na annotation qual
Exception é esperada e pronto:
Ex: @Test(expected=IOException.class)
timeout – este serve testar tempo de execução 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 pós condições
comuns a todos os casos de teste.
É possível ter quantos métodos @Before e @After quiser
Métodos @Before e @After são herdados das superclasses
Métodos @Before das superclasses são executados antes dos métodos @Before da subclasse
Métodos @After das superclasses são executados depois
Objetivo: agrupar código comum a vários 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, não necessitando de nenhum método.
Principais assertivas:
assertTrue(String errorMessage, boolean booleanExpression): Verifica se a expressão booleana é verdadeira.
assertFalse(String errorMessage, boolean booleanExpression): verifica se a expressão 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 não é nulo.
assertNotSame(String errorMessage, Object a, Object b): Verifica se o objeto “a” não é 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 método propositalmente.
failNotEquals(String errorMessage, Object a, Object b): É utilizado para falhar o teste de um método
propositalmente se o objeto “a” não é igual ao objeto “b”.
failNotSame(String errorMessage, Object a, Object b): É utilizado para falhar o teste de um método
propositalmente se o objeto “a” não é igual(semelhante) ao objeto “b”.
Os principais motivos que favorecem o uso desse framework são:
1. JUnit pode verificar se cada unidade de código funciona da forma esperada.
2. Facilita a criação, execução automática de testes e a apresentação dos resultados.
3. É Orientado a Objeto
4. É free e pode ser baixado em: www.junit.org
Como instalar?
Para usar o JUnit em sua máquina basta ter em mente essas duas idéias:
1. Caso você não tenha o JUnit instalado, faça o download do arquivo junit.jar em www.junit.org, após incluao no
classpath para compilar e rodar os programas de teste.
2. Porém o JUnit já vem configurado nas versões recentes de IDE’s como Eclipse, NetBeans, JBuilder, BlueJ e
outros.
Planejando os testes
Metodologias ágeis como Extreme Programming, exigem organização e disciplina, portanto é sugerido que você
faça um bom planejamento antes de sair por aí escrevendo código 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 método de teste para uma tarefa da lista.
3. Rode o JUnit e certifiquese que o teste falha.
4. Implemente o código mais simples que rode o teste.
5. Refatore o código para remover a duplicação de dados.
6. Caso necessário, escreva mais um teste ou refine o existente.
7. Faça esses passos para toda a lista de tarefas.
Arquitetura das classes
Para uma melhor compreensão de como o JUnit funciona é importante que entenda como suas classes estão
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 método a ser testado defina um método 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 gráfico, Veja na Figura 4, que os métodos testados podem apresentar
os seguintes resultados: verde para sucesso, roxo para falha e vermelho para exceção.
Figura 4. Resultados possíveis da execução 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 aplicações Java e por ser um projeto totalmente free que já incorpora em sua instalação, várias
funcionalidades que aplicam práticas XP como refatoração, testes unitários e padrões. Portanto, nesse caso, você
não precisará fazer o download do JUnit e instalálo separadamente, pois o mesmo já está embutido no Eclipse.
Definição de regras a serem seguidas por todos os desenvolvedores com
relação a testes unitários.
Primeiro seleciona a classe a ser testada, click com botão 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 (sugestão que pode ser adotada em
no projeto) defina o diretório a ser criada esta classe Test (ver Figura 6).
Figura 6. Configurando a Classe Teste.
Click em Next e nesta próxima tela defina os métodos a serem testados e depois click em Finish (ver Figura 7) assim
será criado sua respectiva classe de teste.
Figura 7. Selecionando os métodos a serem testados.
Agora é só implementar os testes específicos para cada método selecionado (ver Figura 8).
Figura 8. Ainda falta implementar os testes para esta classe.
Para executar o teste primeiro instale o Plugin do EMMA (eclemma1.4.2) no eclipse.
EMMA é uma ferramenta open source usada para medir e gerar relatórios de cobertura de código Java. E pode ser
utilizada com o JUnit a fim de melhorar a cobertura dos testes, o plugin EclEmma [EclEmma 2008] é empregado
para obter informações sobre os trechos de código do framework JUnit que não são 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 código não exercitado pelos testes necessite ser alterado, outros
testes que exercitam esse trecho devem ser criados, assegurando que os efeitos colaterais introduzidos durantes as
alterações sejam detectados.
A utilização de testes automatizados desde o início do desenvolvimento possibilita ao desenvolvedor cuidar
atentamente de cada parte inserida ou modificada no framework para que a funcionalidade original não seja
alterada. As práticas TDD e refatoração possibilitam que o desenvolvedor realize qualquer tipo de manutenção de
forma mais segura. Adicionalmente, os testes criados também servem como documentação do sistema [Beck 2002]
[Demeyer et al. 2002].
Para instalar o Plugin no eclipse basta descompactar o arquivo eclemma1.4.2.rar e copiar a pasta eclemma1.4.2
para o diretório 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 após executados que no nosso caso não passaram, pois ainda não 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 código 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 rápido / ciclo de teste: Inicia a partir do Eclipse, como execuções de teste JUnit que pode ser
analisado diretamente para a cobertura de código.
Rica Análise de cobertura: Resultados são imediatamente resumidos e destacados nos editores de código
fonte Java.
Nãoinvasivos: EclEmma não requer modificar seus projetos ou realizar qualquer outra configuração.
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 depuração. A modalidade de lançamento de
cobertura pode ser ativado a partir do menu Executar ou a barra de ferramentas:
Após sua aplicação ou teste de unidade ser finalizado as informações cobertura de código é automaticamente
disponível no Eclipse:
Síntese de Cobertura: A vista Cobertura listas resumos cobertura para seus projetos de Java, que permite drill
down para o nível de método.
Fonte destacadas: O resultado de uma sessão de cobertura também é diretamente visível nos editores de
código Java. Um código de cores totalmente personalizável destaca, em parte, e não linhas cobertas. Isso
funciona para o seu próprio códigofonte, bem como para acompanhar a fonte de bibliotecas externas.
Análise de suporte adicionais recursos para sua cobertura de teste:
Contadores diferentes: Selecione se instruções, linhas, blocos básicos, métodos ou tipos de carga deve ser
resumido.
Sessões de cobertura múltipla: É possível alternar entre os dados de cobertura de várias sessões.
Mesclar Sessões: Os vários e diferentes testes devem ser considerados para a cobertura de sessões de
análise que podem ser facilmente fundidos.
Enquanto EclEmma é essencialmente concebido para a execução de teste e análise dentro do Eclipse, ele possui
algumas características de importação / exportação.
Cobertura de importação de dados: Um assistente permite importar arquivos *.ec.
Exportar relatório 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 fácil de utilizar Mock Objects para interfaces de dados.
Objetos Mock simulam partes do comportamento do código de domínio, e são capazes de verificar se eles são
usados como definido. Classes de domínio 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 código gerado!
Benefícios
Não é necessário escrever na mão classes de objetos fictícios.
Apóia a refatoração segura usando Mock Objects: código de teste não vai quebrar em tempo de execução
quando renomear métodos ou parâmetros de método reordenação
Suporta valores de retorno e exceções.
Suporta a verificação da ordem de chamadas de método, por um ou mais objetos Mock.
Desvantagens
EasyMock 2 só funciona com Java 2 versão 5.0 ou superior.
EasyMock por padrão suporta a geração de Mock Objects somente para interfaces. Para aqueles que
gostariam de gerar objetos fictícios para as aulas, há uma extensão disponível na home page do EasyMock.
Instalação
Descompacte o arquivo easymock2.5.1.zip do EasyMock. Ele contém um diretório easymock2.5.1. Adicione o
arquivo JAR do EasyMock, easymock.jar, a partir deste diretório para o seu classpath.
Uso
A maioria das partes de um sistema de software não funciona isoladamente, mas sim colaborar com outras partes
para começar seu trabalho feito. Em muitos casos, não se preocupam com os colaboradores em testes unitários,
como nós 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:
 Share
Forestly Theme | Powered by Wordpress
Cancel

Bases de Dados Distribuidas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Bases de Dados Distribuidas

Enviado por

Direitos autorais:

Formatos disponíveis

13/07/2015 Testes Unitários com JUnit | Anderson Moreira

Você também pode gostar