Outras respostas explicam o que é zombaria. Deixe-me guiá-lo através dele com diferentes exemplos . E acredite, é realmente muito mais simples do que você pensa.
tl; dr É uma instância da classe original. Ele possui outros dados injetados, para que você evite testar as peças injetadas e se concentre apenas em testar os detalhes de implementação de sua classe / funções.
Um exemplo simples:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Como você pode ver, não estou testando a Linha A, ou seja, não estou validando os parâmetros de entrada. Não estou validando para ver se num1, num2 é um número inteiro. Não tenho afirmações contra isso.
Estou apenas testando para ver se a LineB (minha implementação ) forneceu os valores simulados 1e 5está fazendo o que eu esperava.
Obviamente, na palavra real, isso pode se tornar muito mais complexo. Os parâmetros podem ser um objeto personalizado, como Pessoa, Endereço ou os detalhes da implementação podem ser mais do que um único +. Mas a lógica dos testes seria a mesma.
Exemplo sem codificação:
Suponha que você esteja construindo uma máquina que identifique o tipo e o nome da marca de dispositivos eletrônicos para segurança do aeroporto. A máquina faz isso processando o que vê com sua câmera.
Agora, seu gerente entra pela porta e pede que você faça um teste de unidade.
Então, como desenvolvedor, você pode trazer 1000 objetos reais, como um MacBook pro, Google Nexus, uma banana, um iPad etc. na frente dele e testar e ver se tudo funciona.
Mas você também pode usar objetos simulados , como um MacBook pro de aparência idêntica (sem partes internas reais) ou uma banana plástica na frente dele. Você pode evitar investir em 1000 laptops reais e bananas podres.
O ponto é que você não está tentando testar se a banana é falsa ou não. Nem testando se o laptop é falso ou não. Tudo o que você está fazendo é testar se sua máquina, uma vez que vê uma banana que diria not an electronic devicee para um MacBook Pro diria: Laptop, Apple. Para a máquina, o resultado de sua detecção deve ser o mesmo para eletrônicos falsos / simulados e eletrônicos reais
A lógica mencionada acima também se aplica ao teste de unidade do código real. Essa é uma função que deve funcionar da mesma forma com valores reais obtidos com entradas reais (e interações) ou zombadosvalores que você injeta durante o teste de unidade. E da mesma maneira que você evita o uso de uma banana ou MacBook real, com testes de unidade (e zombaria), evita fazer algo que faça com que o servidor retorne um código de status 500, 403, 200, etc. (forçando seu servidor para disparar 500 é apenas quando o servidor está inoperante, enquanto o servidor 200 está ativo.Fica difícil executar 100 testes focados na rede se você precisar esperar constantemente 10 segundos entre alternar entre o servidor ativo e inativo). Então, em vez disso, você injeta / zomba de uma resposta com o código de status 500, 200, 403, etc. e testa sua unidade / função com um valor injetado / zombado.
Exemplo de codificação:
Digamos que você esteja escrevendo um aplicativo iOS e tenha chamadas de rede. Seu trabalho é testar seu aplicativo. Testar / identificar se as chamadas de rede funcionam ou não conforme o esperado NÃO É SUA RESPONSABILIDADE. É responsabilidade de outra parte (equipe do servidor) testá-lo. Você deve remover essa dependência (de rede) e, ainda assim, continuar testando todo o seu código que funciona em torno dela.
Uma chamada de rede pode retornar diferentes códigos de status 404, 500, 200, 303, etc. com uma resposta JSON.
Seu aplicativo deve funcionar para todos eles (em caso de erros, ele deve gerar o erro esperado). O que você faz com zombaria é criar respostas de rede 'imaginárias - semelhantes às reais' (como um código 200 com um arquivo JSON) e testar seu código sem 'fazer a chamada de rede real e aguardar sua resposta de rede'. Você codifica / devolve manualmente a resposta de rede para TODOS os tipos de respostas de rede e verifica se seu aplicativo está funcionando conforme o esperado. (você nunca assume / testa um 200 com dados incorretos, porque isso não é de sua responsabilidade, sua responsabilidade é testar seu aplicativo com um 200 correto ou, no caso de 400, 500, você testa se o aplicativo gera o erro correto)
Esse imaginário criador - semelhante ao real é conhecido como zombaria.
Para fazer isso, você não pode usar seu código original (seu código original não possui as respostas pré-inseridas, certo?). Você deve adicionar algo a ele, injetar / inserir os dados fictícios que normalmente não são necessários (ou parte de sua classe).
Então você cria uma instância da classe original e adicionar o que (aqui é a rede HTTPResponse, dados ou, no caso de falha, você passa o errorString correta, HTTPResponse) você precisa-lo e, em seguida, testar o zombou classe.
Para encurtar a história, zombar é simplificar e limitar o que você está testando e também fazer você alimentar o que uma classe depende. Neste exemplo, você evita testar as próprias chamadas de rede e, em vez disso, testa se o aplicativo funciona ou não conforme o esperado com as saídas / respostas injetadas - zombando de classes
Escusado será dizer que você testa cada resposta de rede separadamente.
Agora, uma pergunta que eu sempre tinha em mente era: Os contratos / pontos finais e basicamente a resposta JSON das minhas APIs são atualizados constantemente. Como posso escrever testes de unidade que levam isso em consideração?
Para elaborar mais sobre isso: digamos que o modelo exija uma chave / campo nomeado username. Você testa isso e seu teste passa. Duas semanas depois, o back-end altera o nome da chave para id. Seus testes ainda passam. direita? ou não?
É responsabilidade do desenvolvedor de back-end atualizar as zombarias. Deveria fazer parte do nosso acordo que eles fornecem zombarias atualizadas?
A resposta para a questão acima é que: testes de unidade + seu processo de desenvolvimento como desenvolvedor do lado do cliente / deveriam receber respostas falsas desatualizadas. Se você me perguntar como? bem, a resposta é:
Nosso aplicativo atual falharia (ou não falhará, ainda não possui o comportamento desejado) sem o uso de APIs atualizadas ... portanto, se isso falhar ... faremos alterações em nosso código de desenvolvimento. O que novamente leva ao fracasso de nossos testes ... e nós vamos ter que corrigi-lo. (Na verdade, se formos fazer o processo TDD corretamente, não escreveremos nenhum código sobre o campo, a menos que escrevamos o teste para ele ... e o veremos falhar e, em seguida, escreveremos o código de desenvolvimento real.)
Isso tudo significa que o back-end não precisa dizer: “ei, nós atualizamos os simulados” ... isso eventualmente acontece através do desenvolvimento / depuração do código. ّ Porque tudo faz parte do processo de desenvolvimento! Embora se o back-end fornecer a resposta zombada para você, será mais fácil.
Meu ponto principal é que (se você não pode automatizar a atualização da resposta da API simulada ), é necessária alguma interação humana, ou seja, atualizações manuais de JSONs e reuniões curtas para garantir que seus valores estejam atualizados se tornarão parte de seu processo
Esta seção foi escrita graças a uma discussão superficial no nosso grupo de reuniões do CocoaHead
Apenas para desenvolvedores iOS:
Um bom exemplo de zombaria é essa palestra sobre protocolo prático de Natasha Muraschev . Pule para o minuto 18:30, embora os slides possam ficar fora de sincronia com o vídeo real 🤷♂️
Eu realmente gosto desta parte da transcrição:
Como isso está testando ... queremos ter certeza de que a getfunção do Gettableé chamada, porque ela pode retornar e, em teoria, a função pode atribuir uma variedade de itens alimentares de qualquer lugar . Precisamos ter certeza de que é chamado;