BT

JUnit 4.7: Per-Test rules

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

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.