A capacidade de escrever bons testes de unidade é um recurso importante de qualquer desenvolvedor. Mas como entender que seus testes de unidade estão corretos? Um bom teste de unidade é como um bom jogo de xadrez. No nosso caso, as peças de xadrez são as abordagens que discutiremos neste post. Não há melhor jogador de xadrez em um jogo de xadrez, porque tudo depende das posições (e de um jogador) . Da mesma forma, no teste de unidade, você não precisa distinguir apenas uma abordagem. Em outras palavras, você deve usar todas as abordagens juntas para obter o melhor resultado. Então, se você quiser ganhar este jogo, seja bem-vindo.
Estréia
Por que devo escrever testes de unidade?
Você não precisa escrever testes de unidade, a menos que seja uma pessoa com percepção extra-sensorial que possa escrever código sem erros, tenha super memória, possa compilar seu código em sua cabeça ou apenas sinta dor. Caso contrário, você definitivamente precisará escrever testes de unidade, porque eles diminuem a contagem de bugs em recursos novos e existentes, reduzem o custo e o medo de alterar seus recursos e permitem refatorar seu código. Além disso, você deve sempre executar testes existentes e eu recomendo que você preste atenção nas ferramentas de teste contínuo.
O que testar?
Obviamente, no teste de unidade, você está testando o comportamento de alguma unidade separada (não invocações, porque elas podem ser alteradas posteriormente) . Além disso, estabeleça uma regra para cobrir com testes de unidade todos os erros que você encontrou para provar que eles foram corrigidos. E a cobertura do código? A cobertura de código não é uma meta, é apenas uma medida que ajuda a entender qual parte da lógica você esqueceu de cobrir com testes de unidade. Seria um erro enorme quando você decidir cobrir todas as linhas de código com testes de unidade.
Mittelspiel
Teste apenas uma coisa
Não confunda teste de unidade com teste de integração, onde o teste de mais de uma coisa é normal. A idéia do teste de unidade é provar que um módulo de aplicativo separado funciona ou não. Você precisa entender fácil e certamente qual comportamento do seu código falha e como corrigi-lo. Quantas afirmações você deve usar? Um! O uso de várias declarações pode ser o cheiro do código que você está testando mais de uma coisa. Além disso, existe a chance de alguém adicionar uma nova afirmação ao seu teste, em vez de escrever outro. E como você pode entender como suas outras afirmações foram concluídas quando a primeira falhou?
Evite a lógica
Erros nos testes são as coisas mais difíceis de encontrar para os desenvolvedores. A chance de obter um bug no seu código de teste aumenta à medida que você decide adicionar lógica ao seu teste. Torna-se mais difícil de ler, entender e manter. Usar for , foreach , if , switch e outros operadores em um teste também pode ser um cheiro de código que você está testando mais de uma coisa.
AAA
O Organizar, Agir, Afirmar é um padrão comumente usado que ajuda a organizar seu código de teste em três fases de acordo. Separa claramente o que está sendo testado das etapas de configuração e verificação. Essa é uma das melhores práticas e torna seu código de teste mais legível e sustentável. Dito isto, não use comentários AAA em seus testes se quiser manter seu código limpo e legível. O teste criado com competência expressa a idéia de AAA, mesmo sem comentários.
Atenha-se à convenção de nomenclatura
Os nomes dos testes devem ser descritivos e compreensíveis, não apenas para o seu autor. Existem muitas estratégias de nomeação de teste, mas eu gosto da de Roy Osherove : [MethodName_StateUnderTest_ExpectedBehavior] . Tem todas as informações necessárias sobre o teste de forma formatada. É fácil seguir essa estratégia para qualquer desenvolvedor.
Exemplos:
public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue ()
Mas preste atenção que você pode ter uma convenção de nomenclatura que deve seguir no seu projeto atual. Não os misture.
Preparação de dados de teste
A construção de dados de teste pode trazer confusão e sofrimento ao seu código de testes. Você pode enfrentar essa situação quando:
- você precisa alterar o construtor do seu modelo em cada parte do código em que esse modelo é criado (isso geralmente acontece quando o modelo é imutável) ;
- você tem muitas duplicatas de código ao criar seus dados de teste;
- você precisa passar muitos "dados mágicos" para o construtor do modelo (por exemplo,
new Device("Stub", 10, true, "http"); ) ; - você sente que precisa criar um tipo de gerador de dados aleatórios;
- é difícil para você criar coletas de dados de testes.
Com isso em mente, você deve considerar algumas alternativas comuns: Mãe do objeto e [Padrão do construtor Fluent]. Essas abordagens também são bons jogadores de equipe, para que você possa usá-las juntas.
Não use dados aleatórios, porque seu teste pode ser sensível a algum tipo de valor. Como resultado, você pode obter heisenbug maligno em seu teste, difícil de encontrar e reproduzir.
Aprenda sua estrutura de teste
Aprenda todos os atributos, asserções e outros recursos da sua estrutura de teste. Isso ajuda você a tornar seus testes mais legíveis e elegantes. Por exemplo, na estrutura do NUnit , você pode usar dois modelos de asserções e escolher o que mais gosta:
Assert.AreEqual(StatusCode.OK, response.StatusCode);
ou
Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode));
Não se esqueça dos métodos de configuração e desmontagem, atributos TestCase e Categoria, declarações de coleção. Não confunda parâmetros de resultados esperados e reais em asserções.
Endspiel
Seu código de teste tem o mesmo privilégio que o código de produção que você precisa escrever e manter, não se esqueça dos princípios do SOLID. Além disso, seus testes de unidade devem ser legíveis e existem várias razões. Em primeiro lugar, a intenção dos seus testes deve ser compreensível e clara. Isso significa que você não precisa perder seu tempo lendo os testes. Em segundo lugar, deve ser fácil manter seus testes, detectar e eliminar problemas sem depuração.
O teste de unidade é uma filosofia enorme que não pode ser discutida apenas em um post. Aqui expliquei abordagens comuns e perguntas frequentes relacionadas ao teste de unidade. Se você quiser mergulhar mais fundo, pode achar esses links interessantes:
Roy Osherove blog
Livro de Roy Osherove, "The Art of Unit Testing"
Mantenha a calma e teste de unidade