e necessario esperar um certo tipo de comportamento consistente com as entradas informadas pelo sistema. Neste caso tambem se encaixa codigo que simplesmente nao roda na maquina do desenvolvedor, como um codigo de acesso ao Active Directory (que necessitaria um infraestrutura imensa somente para executar um teste que deve ser reproduzivel desde que mantidos os parametros de entrada).*Nao e recomendado criar testes para todo e qualquer tipo de codigo. Por exemplo, e insano querer criar qualquer teste para o .NET Framework. Codigo nao testado aqui significa codigo cuja qualidade nao foi verificada.Testes muito lentosTestes demorados significam que os desenvolvedovedores nao os executarao cada vez que uma mudanca e realizada no sistema, ponto. Este unico fator ja deveria ser suficiente para rever os seus testes unitarios ja que uma das maiores vantagens de se desenvolverem tais testes e que qualquer bug inserido no codigo e rapidamente identificado quando os testes falham. Alem disso, existe o custo obvio de produtividade do desenvolvedor que precisa esperar que os testes terminem de executar antes de realizar qualquer alteracao no codigo.Nestas situacoes, quando escrevemos testes para um sistema e nao podemos (ou nao queremos) utilizar um objeto real, nos simplesmente escrevemos um substituto para ele. De modo que o sistema testado acredite que este objeto falso e real.E claro que este objeto falso nao precisa ser a copia do original (implementar todos os membros de uma interface ou sobrescrever todos os metodos de uma classe base) ele somente precisa conter a implementacao necessaria para executar o conjunto de testes. Muitas vezes ate um valor hard-coded e suficiente, em outras, teremos que implementar algum tipo de funcionalidade rudimentar para o teste ter algum valor.A mensagem importante e que nao importa o tipo de objeto falso que voce deseje criar, ele nao pode executar um caminho diferente do objeto real no codigo! Por isso o objeto falso deve ser "instalado" no sistema a ser testado no lugar do objeto real, abaixo temos um exemplo.class ServicoCadastroCliente{ void CadastrarCliente(string nome, string rg) { CadastroCliente cad = new CadastroCliente(); cad.Adicionar(nome, rg); }}class CadastroCliente{ public void Adicionar(string nome, string rg) { //Logica omitida para simplificar exemplo }}.csharpcode, .csharpcode pre{ font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/}.csharpcode pre { margin: 0em; }.csharpcode .rem { color: #008000; }.csharpcode .kwrd { color: #0000ff; }.csharpcode .str { color: #006080; }.csharpcode .op { color: #0000c0; }.csharpcode .preproc { color: #cc6633; }.csharpcode .asp { background-color: #ffff00; }.csharpcode .html { color: #800000; }.csharpcode .attr { color: #ff0000; }.csharpcode .alt{ background-color: #f4f4f4; width: 100%; margin: 0em;}.csharpcode .lnum { color: #606060; }Como eu criaria um objeto falso sem interferir no codigo de producao? O codigo abaixo contem um exemplo: class ServicoCadastroCliente{ ICadastroCliente _cadastroCliente; // Esse e o construtor utilizado pelo codigo de producao, instancia a classe real CadastroCliente void ServicoCadastroCliente() { _cadastroCliente = new CadastroCliente(); } // Esse e o construtor utilizado pelo codigo de teste, o codigo de teste apenas precisa passar uma // instancia de CadastroClienteMock para trocar a classe real pela falsa void ServicoCadastroCliente(ICadastroCliente cadastroCliente) { _cadastroCliente = cadastroCliente; } void CadastrarCliente(string