O teste de métodos privados dependeria de sua complexidade; alguns métodos privados de uma linha realmente não justificam o esforço extra de testes (isso também pode ser dito de métodos públicos), mas alguns métodos privados podem ser tão complexos quanto os métodos públicos e difíceis de testar através da interface pública.
Minha técnica preferida é tornar o private private package, que permitirá o acesso a um teste unitário no mesmo pacote, mas ele ainda será encapsulado em todos os outros códigos. Isso dará a vantagem de testar a lógica do método privado diretamente, em vez de depender de um teste de método público para cobrir todas as partes da lógica (possivelmente) complexa.
Se estiver emparelhado com a anotação @Visiblestrongsting na biblioteca do Google Guava, você estará marcando claramente o método privado desse pacote como visível apenas para teste e, como tal, não deverá ser chamado por nenhuma outra classe.
Os oponentes dessa técnica argumentam que isso quebrará o encapsulamento e abrirá métodos privados para codificar no mesmo pacote. Embora eu concorde que isso rompa o encapsulamento e abra código privado para outras classes, eu argumento que testar lógica complexa é mais importante que o encapsulamento strict e não usar métodos privados de pacotes que estão claramente marcados como visível apenas para teste deve ser de responsabilidade dos desenvolvedores usando e alterando a base de código.
Método privado antes de testar:
private int add(int a, int b){
return a + b;
}
Método privado do pacote pronto para teste:
@VisibleForTesting
int add(int a, int b){
return a + b;
}
Nota: Colocar testes no mesmo pacote não é equivalente a colocá-los na mesma pasta física. Separar seu código principal e código de teste em estruturas de pastas físicas separadas é uma boa prática em geral, mas essa técnica funcionará enquanto as classes estiverem definidas no mesmo pacote.