Na Aula 3 - Atividade 08, o Daniel comenta sobre o teste de métodos privados.
Geralmente os métodos privados são chamados por métodos públicos, como ele comentou, até aí tudo bem. É difícil pensar em exemplos assim a toque de caixa, mas digamos que nós tenhamos um método público IniciarProcessoComplexo() que, internamente, chama o mesmo método privado com diferentes parâmetros.
Geralmente, quando falamos de TDD, utilizamos também alguma ferramenta de Mock nos Unit Tests. No caso do método IniciarProcessoComplexo(), na seção Arrange, teríamos várias linhas de código para "preparar" o teste, ou seja, fazer o setup de todas as chamadas internas, para, só no final, fazer a chamada de um método público. Eu entendo que em grande parte dos casos isso significa que a abstração não está correta, ou seja, que algum desses métodos deveria ter sua implementação feita em uma classe distinta, de forma que a interface pudesse ser injetada no método IniciarProcessoComplexo() e mockada nos testes unitários. Mas eu estou focando aqui em métodos privados que são utilizados apenas para melhorar a organização e legibilidade do código. Como por exemplo, verificar se um parâmetro de entrada é válido, efetuar operações de IO, etc., ou seja, operações de "house keeping", que tratam apenas de detalhes de implementação, não fazendo parte do quadro geral do cenário.
Tem também a situação em que a complexidade ciclomática do código é alta, ou seja, existe um número grande de "caminhos de execução" que o código pode seguir (switchs, ifs, desvios em geral).. nesse caso é melhor testar todos os caminhos em um único teste, passando os casos como parâmetros no método e (Theory/Inline Data) ou criar um teste para cada caminho de execução?
Gostaria que a comunidade pudesse comentar essa thread contando suas experiências, o que deu certo/boas práticas mas, principalmente, o que deu errado..
Valeu pessoal, abs
