É uma prática ruim separar os testes de unidade para uma classe? [fechadas]

Minhas classes normalmente têm no máximo de 5 a 20 métodos, o que implica que a classe que possui os testes de unidade possui aproximadamente o dobro de métodos (contando dataProviders, setUp, ...)

Eu pensei em separar os testes em 2 a 3 classes, porque mesmo se eu tentar seguir o princípio de responsabilidade única, prefiro 2 classes de testes com 10 métodos cada, do que uma com 20.

É uma má prática? É bom ter todos os testes de uma classe em apenas um, embora a classe de teste cresça na vertical?

Para responder a uma pergunta específica, é absolutamente possível que agrupar testes em várias classes seja uma boa decisão, evento quando a classe em teste for bem projetada.

O código do teste de unidade é como qualquer outro código: ele deve seguir bons princípios de design ( SECO , GRASP , KISS , SÓLIDO , YAGNI , etc.). Como a lógica que compõe o código de teste geralmente é mais simples que a lógica do domínio, muitos pontos específicos não surgem tanto, mas lembre-os enquanto escreve os testes da mesma forma.

Existem alguns princípios que vêm à mente que podem ser facilmente aplicados ao pensar em sua pergunta:

Legibilidade

Idealmente, depois que um teste é escrito, você nunca mais precisa vê-lo; mas o mesmo pode ser dito para qualquer código. A realidade é que os requisitos mudam, então nos encontramos lendo muito mais do que escrevendo. Mesmo ao fazer o seu melhor, você pode achar que o teste que você escreveu não verificou exatamente o que você pensou que fez; nesse momento, você terá que voltar e descobrir o que estava errado. Encontrar esse método de teste em uma classe de 40 a 50 métodos de teste será difícil, sem mencionar a complicação de nomear esses métodos para que eles possam ser diferenciados facilmente.

Coesão alta

Cada classe de teste (como qualquer outra classe) deve ter um foco claro. Se você tiver muitos casos de teste diferentes para um determinado método da classe em teste, como quando um determinado teste verifica uma coisa, coloque esses métodos em uma classe separada e nomeie-o para refletir seu foco.

É quase sem importância como os testes de unidade são organizados em comparação com os testes em primeiro lugar.

Um módulo ou classe de código de negócios é algo que você precisa entender como uma unidade e desenvolver ainda mais. Essa é a principal razão pela qual nos esforçamos para torná-la coerente, fácil de entender como um todo, etc. Uma suíte de testes é apenas uma coleção de casos que devem ser aprovados; o não tem nenhum relacionamento particular um com o outro . Idealmente, você nunca terá que lidar com isso novamente; se você fizer isso, geralmente adicionará mais testes que, novamente, não têm relação específica com nenhum outro teste, e eles nunca são chamados pelo código do cliente, exceto pela estrutura de teste da unidade.

Portanto, a questão de como organizar as classes que contêm testes de unidade é muito menos crítica do que como organizar as classes que compõem seu próprio aplicativo. Você não deve lidar com eles como uma macroestrutura bem arquitetada de qualquer maneira.

Coloque os testes em um arquivo. Normalmente, para cada arquivo de classe, eu teria um arquivo de teste. Geralmente adicione "Testes" ao nome do arquivo.

Por exemplo, se houver uma classe chamada "Foo", haverá um arquivo "FooTests" correspondente. Dessa forma, para cada arquivo de código, há um relacionamento de 1 para 1 entre o arquivo de código e o arquivo de teste.

Isso fornece consistência e facilita para os desenvolvedores localizar os testes e mantê-los atualizados. Os testes geralmente são excluídos da análise / métrica de código; portanto, se o arquivo for grande, não prejudicará a métrica geral de integridade do código; portanto, não considero incorreto ter um arquivo de teste com muito código de teste de unidade.

Se dissermos que a definição de práticas inadequadas no desenvolvimento de software é algo que não ajuda a lidar e encapsular a mudança, eu diria que não manter suas classes e testes em um relacionamento individual é uma prática ruim . É um cheiro de código que pode surgir devido às coisas mencionadas abaixo.

Obviamente, há exceções como qualquer outra coisa, mas lembre-se disso ao escrever seus testes.

Minhas aulas normalmente têm de 5 a 20 métodos no máximo.

Se alguma de suas aulas tiver 20 (ou um pouco menos) métodos, isso me mostra que a classe está fazendo muito em primeiro lugar. É aqui que os testes de unidade devem sugerir que você pode precisar dividir um pouco mais sua classe e distribuir a responsabilidade antes de fazer os testes.

Quanto a mantê-los na mesma classe ou não, eu sugeriria tentar mantê-los em uma classe, se possível, porque é melhor compreensível - é fácil entender a conexão de um para um após muito tempo. Apenas por experiência.

Se você perceber que os testes de unidade são enormes, mesmo quando você tem 5 métodos ou menos, isso indica que seu código de configuração está fazendo muito ou que seus objetos são anormalmente grandes .

Se você ainda não experimentou, verifique o padrão do construtor para construir seus objetos - isso pode reduzir drasticamente o código de como você está construindo seus objetos antes de testá-los. Portanto, tornando a classe de teste de unidade mais curta e menos necessária, você deve dividi-la em mais classes.