Respostas:
A organização dos seus testes não é importante em comparação com a importância de tê-los.
O mais importante para um bom conjunto de testes é que ele cubra toda a funcionalidade; isso garante que sempre que um defeito de regressão for introduzido, você notará imediatamente. Escrever um teste para cada método, um teste para cada combinação de valor de entrada de um método ou mesmo um teste para cada caminho de código possível dentro desse método é menos importante. Organizar esses testes em poucas ou muitas classes de teste é ainda menos importante: um conjunto de testes deve sempre ter êxito na íntegra, por isso não importa se falha em um dos três ou dois dos dezessete testes - ambos estão errados e devem ser fixo.
Obviamente, o código de teste também é código, portanto deve seguir as práticas recomendadas normais para manutenção, modular etc. Mas isso deve ser decidido pela manutenção da suíte de testes, e não pela maneira como as classes de teste se relacionam com o classes que eles testam. Ambas as políticas mencionadas podem ajudá-lo a lembrar onde encontrar as coisas, se você as seguir de maneira consistente, mas, para isso, a consistência é mais importante do que a escolha da política.
Para sua pergunta específica, a convenção JUnit, é ter uma correspondência 1: 1 entre as classes de aplicativo ( Foo1.java, Foo2.java) e as classes de teste JUnit ( Foo1Test.java, Foo2Test.java).
Dito isto, concordo plenamente com o destaque de Kilian da importância do espírito / objetivos dos testes de unidade sobre quaisquer esquemas organizacionais que possam ser usados. Escolha algumas convenções e atenha-se a elas a maior parte do tempo, ao mesmo tempo em que permite exceções às suas convenções, quando justificadas.
É melhor ter uma classe separada para cada método ou apenas uma classe de teste para cada classe real?
Se você precisar escrever classes de teste separadas para métodos de uma classe, terá o design errado. Os métodos devem ser pequenos, fáceis de ler, fáceis de testar e fáceis de mudar. Os testes podem ser um pouco mais longos que o código original devido à criação de dados de teste, zombaria etc., mas não devem ser significativamente mais longos. Se forem, sua classe em teste é muito complexa e faz com certeza mais de uma coisa ( princípio de responsabilidade única ): trabalhe em seu projeto.
Eu acho que "uma classe de teste por método" e "uma classe de teste por classe" são geralmente muito extremas.
Em geral, você deseja fazer uma verificação por método de teste / teste de unidade. Por exemplo, essas podem ser várias asserções para verificar se um list.isEmpty = truee list.Length = 0, portanto, um método de teste / teste de unidade por comportamento.
Isso facilita a criação de um nome de método de teste que descreva o comportamento. Você deseja agrupar métodos de teste em uma classe de teste; portanto, quando você lê o texto test classname.test method, faz sentido. Geralmente, eles têm algum código de configuração compartilhado que é fácil de colocar na instalação / equipamento de teste. Dependendo da classe em teste, pode ser uma classe de teste para toda a classe e também pode ser uma classe de teste para um método. Mas geralmente, estará em algum lugar no meio.
Como no código normal, você deseja ter os testes o mais legíveis possível. O que ajuda para mim é seguir o estilo de organizar o código de teste do BDD dado quando e quando organizar ou agir. Uma classe de teste poderia ter dado isso, é a configuração. Então, todo método de teste nessa classe usa o dado (ou parte dele) e possui um quando e um então.
Pense também nos testes de unidade como documentação sobre como usar a funcionalidade da classe em teste. Com bons testes de unidade, você pode ler os testes para descobrir como usar a funcionalidade da classe que deseja usar e quais serão os efeitos exatamente.
Quando algo quebra e um teste de unidade falha, você quer que seja o mais fácil possível para entender o que quebrou, uma afirmação por teste ajuda muito aqui. Quando há várias asserções em um teste, apenas a primeira falha e o método é encerrado, portanto, você não sabe se o outro comportamento testado nos testes a seguir também está quebrado até que você corrija o que fez a primeira afirmação falhar. Com uma afirmação, todos os outros métodos de teste ainda são executados e é muito mais rápido entender a profundidade da falha.
Obviamente, eu concordo com Kilian Foth: na prática, você pode ter a sorte de ter alguns testes de unidade para o código no qual está trabalhando. E qualquer pequeno teste localizado é melhor do que nenhum teste, ou apenas grandes testes de integração executados no servidor de compilação levam muito tempo e geralmente não são muito localizados (eles não informam rapidamente onde está o erro - você terá que trabalhar um pouco nisso).
Acho certo que cada classe tenha sua classe de teste. A idéia é centralizar todos os testes de unidade relacionados à classe de destino em uma única classe de teste. Então, por exemplo, MyClass.javasua classe de teste será chamada MyClassTest.java.