Devo separar testes de unidade e testes de integração?

Eu tenho que escrever testes de unidade e testes de integração para um projeto.

Todos os testes devem ser colocados em uma única pasta de testes ?
Ou os testes de unidade e de integração devem estar em uma pasta de testes separada ?
Ou devo colocá-los em projetos separados ?

Se eu os mantiver juntos, existem vantagens ou desvantagens nessa abordagem?

architecture unit-testing integration-tests

— Ahmed Ragheb
fonte

Se você estiver operando em um ambiente de IC, o importante é que eles possam ser facilmente identificados (por atributo, etc.), pois os testes de integração nem sempre são executados no servidor de construção.

— Robbie Dee

Relacionados: Teste: unidade x integração x outros, qual é a necessidade de separação?

— Mouviciel 17/01/19

Em geral: sim, você deve colocar testes de integração e testes de unidade em pastas diferentes. Frequentemente, os programadores não traçam uma linha clara entre esses dois tipos de testes e apenas escrevem qualquer tipo de teste que seja útil. Mas os testes de integração tendem a ser mais lentos, porque geralmente envolvem:

Consultas de banco de dados
Solicitações de rede
Comportamento dependente do tempo
Grandes quantidades de dados

Por outro lado, um teste de unidade zombaria de quaisquer operações caras, portanto, os testes de unidade tendem a ser executados rapidamente (na verdade, a parte mais lenta da execução do teste é geralmente a própria estrutura de teste).

Quando um programador está trabalhando no sistema, ele está em um ciclo de edição e teste. Quanto mais rápido eles obtêm feedback de teste e quanto menor o ciclo, mais produtivos eles podem ser. Portanto, queremos executar apenas testes importantes que são concluídos rapidamente. O conjunto completo de testes seria executado apenas como parte de um processo de controle de qualidade, por exemplo, em um servidor de IC.

Isso significa que grandes suítes de teste devem ser categorizadas. Podemos selecionar apenas testes de unidade para um componente específico? Podemos excluir testes lentos? Uma maneira simples de fazer isso é manter diferentes conjuntos de testes em diretórios diferentes. Se você tiver apenas muito poucos testes, um único diretório também estará OK, desde que um programador possa selecionar facilmente um subconjunto de testes.

Tudo o que permite que um programador obtenha feedback rapidamente é bom. O conjunto de testes mais abrangente não importa se não for executado regularmente.

Leitura adicional:

Teste: unidade vs. integração vs. outros, qual é a necessidade de separação? que foi vinculado pelo mouviciel acima.
Devo separar testes de unidade dos testes de integração? no meu blog, que discute essa resposta com mais detalhes.

— amon
fonte

Ao separar as pastas, você mantém cada uma delas no mesmo pacote que o código de produção (para poder testar métodos protegidos)? Por exemplo, você cria um módulo de preparação para testes de unidade e outro módulo de preparação para os testes de integração. Assim, você pode separá-los e ainda testar facilmente métodos protegidos.

— Ihebiheb

@ihebiheb Em Java, o uso da visibilidade do pacote é bastante desaprovado. Em alguns casos, pode ser útil usá-lo e acessar essas APIs a partir de testes de unidade. Mas, em geral, isso é desnecessário. Os testes no estilo de integração nunca precisam de acesso a membros privados do pacote. A colocação ou não dos testes em um projeto Maven separado depende de como você deseja executá-los e implantá-los. Não gosto muito de Java / Maven para poder dizer o que é sensato aqui.

— amon