Por que os frameworks xUnit não permitem que os testes sejam executados em paralelo?

15

Você conhece algum framework xUnit que permita executar testes em paralelo, para usar vários núcleos na máquina atual?

Se nenhum (ou poucos) deles fizer isso, talvez haja uma razão ... Será que os testes geralmente são tão rápidos que as pessoas simplesmente não sentem a necessidade de paralelizá-los?

Existe algo mais profundo que impeça a distribuição (pelo menos alguns) dos testes em vários threads?

    
por Xavier Nodet 08.03.2011 / 21:42
fonte

6 respostas

6

NUnit 2.5 empacotado pNUnit que permite a execução de testes em paralelo.

This release includes pNUnit, an extended NUnit runner for distributed parallel tests. The pNUnit program was developed at Codice Software for use in testing the Plastic SCM and has been contributed to NUnit. For more info about using pNUnit see the pNUnit site.

O lado da JUnit tem paralelo-junit , bem como amino .

    
por 08.03.2011 / 21:51
fonte
10

Para responder à segunda parte da sua pergunta: Existe algo mais profundo que impeça a distribuição (pelo menos alguns) dos testes em vários segmentos?

Uma grande quantidade de código só funciona quando é executado um único thread. É trivial produzir acidentalmente contenção de recursos e bloqueios ao escrever programas com base no pressuposto de que eles serão executados com encadeamento único. E isso funciona bem porque a maioria dos programas realmente executa um thread único. O paralelismo é obtido pela execução de várias cópias, ou programas diferentes ao mesmo tempo (scripts da web sendo um exemplo comum - muitos usuários acessando uma única página significam muitas cópias dos scripts para essa página em execução ao mesmo tempo).

Imagine uma classe simples "log to file". Quando você cria uma instância, ela abre o arquivo para gravação, quando você libera a instância, ele fecha o arquivo. Assim, o primeiro teste cria uma instância e começa a executar um teste. O segundo teste faz a mesma coisa em um segundo thread. E falha, porque a segunda instância não pode obter acesso de gravação ao arquivo. Mas se for executado um de cada vez, todos os testes passarão.

Tudo isso pode ser codificado, e o exemplo simples pode ser ajustado para funcionar. Mas fazer isso é provavelmente desnecessário para o programa original . Ter que escrever código thread-safe apenas para que você possa executar testes de unidade não é razoável para muitas pessoas. Portanto, os testes unitários multithread devem permanecer como um extra opcional.

    
por 08.03.2011 / 22:10
fonte
4

Se os testes precisarem ser configurados e consultados em um banco de dados, os testes em paralelo interferirão uns com os outros, a menos que haja um banco de dados separado para cada teste executado em paralelo.

    
por 08.03.2011 / 21:56
fonte
2

Embora o JUnit, por si só, possa não permitir (eu não estou intimamente familiarizado com suas versões mais recentes), o Maven com seu plugin Surefire tem uma opção para executar testes em paralelo. Ainda não tentei ainda.

Não estou strongmente pressionado para investigar essa opção, pois temos apenas um pouco mais de mil testes e eles correm rápido o suficiente. No entanto, eu sei que alguns dos equipamentos de teste têm dependências implícitas entre (nós encontramos algumas dessas dependências quando alguns testes quebraram inesperadamente no passado), então há um risco em que a paralelização dos testes fará com que alguns deles falhem imprevisivelmente. Você pode dizer que isso é bom, pois torna o problema explícito. No entanto, estamos lidando com um sistema legado e temos muitas questões mais importantes para lidar - o tempo é um recurso escasso (como sempre).

    
por 08.03.2011 / 22:25
fonte
0

A codificação multithread não é trivial. Mesmo quando feito por pessoas que sabem o que estão fazendo, erros dependentes do tempo podem ocorrer. Eles são difíceis de consertar. Tendo lidado com alguns milhares de erros de tipo de caso que podem ser produzidos por vários passos, eu preferiria não tê-los em minha estrutura de testes. A primeira correção que recebi pareceu funcionar, mas em testes posteriores descobriu-se que ela havia se tornado uma em dezenas de milhares de bugs.

As técnicas para multi-threading em multiprocessadores estão melhorando com o advento de PCs multi-processadores. No entanto, levará algum tempo até que eles estejam em uso amplo.

Alguns conjuntos de testes têm dependências entre testes que não precisam ser explicitamente declarados quando os testes são executados em um único fluxo. No entanto, em um mecanismo multi-vapor, eles precisariam ser explicitamente declarados. (Onde tais dependências devem existir é uma questão diferente.)

De outro ponto de vista, algumas coisas simplesmente não precisam ser executadas em paralelo. Se o processo for executado de forma adequada e rápida, é melhor concentrar os esforços em outras coisas além da implementação de multiencadeamento.

    
por 09.03.2011 / 00:05
fonte
0

O MBUnit é capaz de executar testes em paralelo simplesmente especificando alguns atributos de nível de montagem.

[assembly: DegreeOfParallelism(6)]
[assembly: Parallelizable(TestScope.All)]

Eu tenho usado esse projeto para executar testes de selênio em paralelo com bastante sucesso por algum tempo. Infelizmente o projeto não está mais vivo.

O xUnit 2.0 também deve suportar testes de unidade paralela, mas ainda não testei.

    
por 22.11.2013 / 10:55
fonte