InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

JUnit 4.7: Per-Test rules

Postado por Geoffrey Wiseman , traduzido por Fernanda Stringassi de Oliveira em 30 Jul 2009

Seções
Arquitetura e Design,
Desenvolvimento
Tópicos
Java ,
Websphere ,
Extensibility ,
Linguagens ,
Programação ,
IBM ,
Servidores de Aplicação ,
OOP ,
JUnit ,
Agile nas empresas ,
Testes Unitários ,
Metodologias ,
Agile ,
Testes ,
TDD

O JUnit 4.7, que acabou de alcançar o estágio de Release Candidate ,  inclue uma nova funcionalidade significativa: Rules.

Rules é, essencialmente, um outro mecanismo de extensão para o JUnit, que pode ser usado para adicionar funcionalidade para o JUnit por teste. A maioria dos exemplos dos custom runners em versões anteriores podem ser substituídos por Rules . Como descrito em uma versão anterior desta notícia  sobre a funcionalidade:

No JUnit 3 você também podia manipular o processo de execução dos testes de várias formas. Um dos preços da simplicidade do JUnit 4 foi a perda do “meta-testing”. Ele não afeta testes simples, mas para testes mais robustos pode ser um limitante. O estilo da estrutura de objetos do JUnit 3 continuou como padrão. Já o estilo DSL do JUnit 4 não. Na última noite nós trouxemos o “meta-testing” de volta, mas muito mais limpo e simples do que antes.

Complementando a capacidade de criar regras, algumas regras principais foram adicionadas:

  • TemporaryFolder: Permite que o teste crie arquivos e diretórios com garantia de que serão excluídos depois da execução do teste. Esta é uma necessidade comum para testes que trabalham com o sistema de arquivos e querem executar de forma isolada.
  • ExternalResource: Um padrão para recursos que precisam ser inicializados com antecedência e com garantia de ser destruído depois da execução dos testes. Será útil para testes que trabalham com sockets, servidores embutidos, e similares.
  • ErrorCollector: Permite que o teste continue a executar depois de uma falha e reporte todos os erros até o final do teste. É útil quando um teste verifica um conjunto de condições independentes (apesar de o próprio teste poder ter uma falha).
  • ExpectedException: Permite ao teste especificar tipos e mensagens de exceções esperadas no próprio teste.
  • Timeout: Aplica o mesmo tempo de expiração para todos os testes em uma classe.

Se você gostaria de ver um exemplo de regra em ação, aqui está um teste usando as regras TemporaryFolder e ExpectedException:

public class DigitalAssetManagerTest {
        @Rule
        public TemporaryFolder tempFolder = new TemporaryFolder();
        @Rule
        public ExpectedException exception = ExpectedException.none();
        @Test
        public void countsAssets() throws IOException {
               File icon = tempFolder.newFile("icon.png");
               File assets = tempFolder.newFolder("assets");
               createAssets(assets, 3);
               DigitalAssetManager dam = new DigitalAssetManager(icon, assets);
               assertEquals(3, dam.getAssetCount());
        }
        private void createAssets(File assets, int numberOfAssets) throws IOException {
               for (int index = 0; index < numberOfAssets; index++) {
                       File asset = new File(assets, String.format("asset-%d.mpg", index));
                       Assert.assertTrue("Asset não conseguiu ser criado.", asset.createNewFile());
               }
        }
        @Test
        public void throwsIllegalArgumentExceptionIfIconIsNull() {
               exception.expect(IllegalArgumentException.class);
               exception.expectMessage("Icon está null, não é um arquivo, ou não existe.");
               new DigitalAssetManager(null, null);
        }
}

Para fazer o desenvolvimento das regras mais fácil, algumas classes de base para regras foram adicionadas:

  • Verifier: Uma classe de base para regras como ErrorCollector que podem transformar testes com falhas em testes com sucesso se uma condição de verificação falhar.
  • TestWatchman: Uma classe de base para regras que observam a execução dos testes sem modificar os resultados.

Rules eram chamados como Interceptors (interceptadores) quando eles fizeram a primeira aparição nos primeiros builds do JUnit 4.7. Além das regras, o JUnit 4.7 também contém:

  • Algumas mudanças para os matchers.
  • Testes que expiram agora apresentam o stack trace; isto pode ajudar a diagnosticar a causa da expiração do teste.
  • Melhorias no Javadoc e alguns bugs corrigidos.

Mais informações sobre estas funcionalidades estão disponíveis no JUnit 4.7 release notes. Suporte para o Hamcrest 1.2 foi listado nos release notes anteriores, mas foi retirado desta versão.

Enquanto você está esperando pela versão final, você pode fazer o download do release candidate do github, procurar apetrechos do org.junit.rules, preencher a pesquisa , ler sobre o deadpooling do JUnit Max do Kent Beck, e esperar a reação dos usuários do JUnit 4.7 nos blogs, friendfeed twitter.

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.