Testes Unitários com JUnit

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. Considera-se 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. 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.

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.

Caixa-branca

Também chamada de teste estrutural ou orientada à lógica, a técnica de caixa-branca 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.

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 caixa-branca é 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.

Caixa-preta

Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta 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 caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se 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, pode-se 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 caixa-preta é 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. Inclui-se 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ão-funcionais 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 dia-a-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 referindo-se 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 inclua-o 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 certifique-se 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 (eclemma-1.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 eclemma-1.4.2.rar e copiar a pasta eclemma-1.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ão-invasivos: 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ódigo-fonte, 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.

  1. No comments yet.
Comments are currently closed.
Trackbacks & Pingbacks ( 0 )
  1. No trackbacks yet.