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.

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 menssagens dessa discussão
Comentários da comunidade

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

Receber menssagens dessa discussão

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

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT