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.
Notícias
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
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 e twitter.
Nenhum comentário
Acompanhar Discussão Responder