Noesta discussão, Brian (o único atendedor) diz "Seu código deve ser escrito de tal maneira que seja independente de teste"

O único comentário diz "Seu código definitivamente não deve se ramificar em um sinalizador global" estou sendo testado ".".

Mas nenhum deles dá razões, e eurealmente gostaria de ouvir alguns pensamentos racionais sobre o assunto. Seria imensamente fácil (principalmente considerando o fato de muitos testes terem acesso privado ao pacote às classes de aplicativos) acessar uma determinada classe de aplicativo e definir um booleano para dizer "este é um teste, não uma execução".

Todos os tipos de coisas que eu me pego pulando através de aros (campos privados simulados injetados, etc.) para conseguir podem se tornar mais fáceis de realizar.

Também é óbvio que se você levar isso longe demais, pode ser desastroso ... mas como uma ferramenta entre muitas no arsenal de testes de software, por que o conceito se encontra com tanto opróbrio?

Resposta a Mick Mnemonic:

Um exemplo trivial de como isso poderia ajudar seria se você estivesse criando uma nova instância de classe no meio de um método e atribuindo-a a um campo privado: as zombarias de campos privados não ajudarão nesse caso, porque você está substituindo o privado campo. Mas, na verdade, a criação de um objeto real pode ser muito dispendioso: você pode substituí-lo por uma versão leve ao testar.

Na verdade, eu encontrei essa situação ontem ... e minha solução foi criar um novo método privado de pacote chamado createXXX () ... para que eu pudesse zombar dele. Mas isso, por sua vez, vai contra o ditado "você não deve criar métodos apenas para se adequar aos seus testes"!