Testes de Unidade

Testes de unidade são o processo em que você testa a menor unidade funcional de código.

Os sistemas, funções e trechos de código, todos têm uma entrada e uma saída esperada. Para ter certeza de que tudo está funcionando direitinho, a gente precisa de testes, sejam manuais ou automatizados, que checam a entrada e saída, garantindo que tudo saia como esperado.

Com os testes antes do uso “oficial” do sistema/projeto, você garante que não acontecerá falhas básicas e que seu sistema não corre riscos de falha.

🤪 “Pô Bê, mas eu tenho certeza absoluta que meu código ta certo, pra que testar?” Junior… Junior… vamos colaborar né. O teste ta aí pra ser feito e a gente vai entender o pq.

Por que testar?

• É uma maneira de exercitar sua lógica, validando se a mesma faz sentido
• Evitar erros bobos que codificação que podem gerar um enorme transtorno
• Construir um suite de testes é fundamental para uma refatoração futura de seu código

Alguns tipo de testes

Existem vários tipos de testes, porém os 3 tipos mais relevantes que são:

• Caixa Branca - Este teste é realizado pelos desenvolvedores
• Caixa Preta - Este é realizado pelo controle de qualidade de software (QA)
• Aceitação - Este é realizado pelos usuários finais da aplicação;

🤪 O segredo pra não ficar igual o Bob Esponja deprimido é não falhar no teste de aceitação, o que vai te ajudar nisso? HAHA TESTAR NÉ

🤪 Um pessoal que ja trabalha na área fala, “ah mas meu colega não testa, ah mas todo mundo aqui sobe sem testar”, resposta básica que mamãe ensinou lá no prézinho. VOCÊ NÃO É TODO MUNDO

Para o desenvolvimento em equipe, os testes automatizados são super importantes porque eliminam a chatice dos testes repetitivos sempre que alguém mexe no sistema. Além disso, permitem reutilizar componentes rapidinho, já que os resultados são previsíveis e fáceis de verificar.

🤪 “Ok Bê estou convencido/a, como testa?” Agora sim, música para os meus ouvidos.

xUnit

O xUnit é um framework para testes unitários que é flexível e completo, além de ser parte do .NET Foundation e ter sido escrito pelo criador da v2 do NUnit.

Pra começar, o ideal é que criemos uma solution e então dois projetos dentro dela. Um sendo nossa aplicação e outro sendo o projeto de testes. Eu criei duas pastas vázias pra começar, Calculadora e CalculadoraTest.

Agora pra facilitar vamos pro terminal. Certifique-se que o caminho do seu terminal está correto.

• Entrar na pasta calculadora e criar um console app
• Entrar na pasta calculadora test e criar um xunit

Com a extensão vscode-solution-explorer, criei uma solution e vinculei os dois projetos à ela.

Agora, precisamos fazer nossos projetos “se conhecerem” visto que calculadora teste vai testar o que tem em calculadora. Pra isso, vamos novamente usar essa extensão e adicionar a referência.

Feito isso, ao ir no arquivo .csproj do nosso projeto CalculadoraTest, é essa referência que vai encontrar.

<ItemGroup>
    <ProjectReference Include="..\\Calculadora\\Calculadora.csproj" />
</ItemGroup>

Agora sim podemos enfim testar algo.

Padrões de nomenclaturas

Geralmente um dos grandes desafios sobre testes de unidade é definir bem o que está sendo testado, com esta afirmação os padrões de nomenclatura dos testes nos ajuda a não nos perder no que de fato importa para nossos testes.

👉🏼 Um bom padrão de nomes para testes seria a combinação a seguir: contexto_metodo_resultadoEsperado();

Estrutura dos testes

O código de teste precisa estar organizado, assim como o código do sistema. Se alguma regra do sistema mudar, o teste precisará de manutenção. E uma boa prática para isso é definir três áreas dentro de cada método de teste:

• Arrange: nesta seção você prepara todo o setup do seu teste criando as variáveis que serão utilizadas.
• Act: aqui você invoca o método que será testado.
• Assert: aqui você coloca as verificações que serão necessárias para garantir que seu teste deu certo ou não.

Essas “seções” são meramente comentários para fins de organização.

Pode parecer bobo, mas é uma mão na roda quando você está um tanto perdido no que está fazendo.

[Fact]
public void Test1()
{
 //Arrange

 //Act

 //Assert
 }

No contexto de testes unitários usando xUnit, [Fact] e [Theory] são dois tipos de atributos que você pode usar para definir e organizar seus testes

Um [Fact] é um teste simples que não depende de nenhum dado externo. Ele é usado quando você quer testar um comportamento específico de maneira direta, sem precisar de entradas variadas.

Um [Theory] é usado para testes parametrizados, ou seja, testes que são executados várias vezes com diferentes conjuntos de dados. Você pode passar diferentes valores de entrada para verificar se o comportamento do código se mantém consistente.

Enfim vamos aos testes. Pra começar vamos fazer nossa classe de domínio calculadora.

namespace Calculadora;

public class Calculadora
{
  private List<string> historicoList;

  public Calculadora()
  {
      historicoList = new List<string>();
  }
  public int somar(int numero1, int numero2)
  {
      int resultado = numero1 + numero2;
      historicoList.Insert(0, "resultado = " + resultado);
      return resultado;
  }
  
  public int subtrair(int numero1, int numero2)
  {
      int resultado = numero1 - numero2;
      historicoList.Insert(0, "resultado = " + resultado);
      return resultado;
  }
  
  public int multiplicar(int numero1, int numero2)
  {
      int resultado = numero1 * numero2;
      historicoList.Insert(0, "resultado = " + resultado);
      return resultado;
  }
  
  public int dividir(int numero1, int numero2)
  {
      int resultado = numero1 / numero2;
      historicoList.Insert(0, "resultado = " + resultado);
      return resultado;
  }

  public List<string> historico()
  {
      historicoList.RemoveRange(3, historicoList.Count - 3);
      return historicoList;
  }
}

Agora com base nessa classe vamos fazer nossa classe de testes.

Neste teste estamos testando se o método de somar funciona, vamos destrincha-lo

using Calculadora;

namespace CalculadoraTests;

public class UnitTest1
{
  [Fact]
  public void TestSoma()
  {
          //Arrange
      Calculadora calc = new Calculadora();

              var num1 = 2;
              var num2 = 3;
              
              //Act
      var result = calc.somar(num1, num2);
      
      //Assert
      Assert.Equal(5, result);
  }
}

• Primeiro montamos nosso cenario, instanciamos a nossa classe calculadora, criamos duas variáveis e atribuímos valores numéricos.
• Em seguida, no act, testamos o método somar.
• Pra finalizar, no assert, ele faz a comparação entre o que você espera que o código produza e o que ele realmente produziu. No caso estamos vendo se 5, o resultado esperado da soma, é igual a result, que trará o resultado da soma.

🤪 Viu?? Testar não é tão complicado assim é?

TDD

Test Driven Development

👉🏼 Desenvolvimento orientado a teste

Trata-se de uma maneira de desenvolver software onde a gente começa a codar as funcionalidades escrevendo testes unitários. Essa técnica foi criada pelo Kent Beck e é uma das bases do XP.

Essa prática segue um ciclo de desenvolvimento onde seu código é testado antes mesmo de existir. Assim, a lógica é super exercitada durante o desenvolvimento.

Motivos para utilizar TDD

• Feedback rápido sobre a nova funcionalidade e sobre as outras funcionalidades existentes no sistema
• Segurança no Refactoring pois podemos ver o que estamos ou não afetando
• Código da aplicação mais flexível, já que para escrever testes temos que separar em pequenos "pedaços" o nosso código, para que sejam testáveis, ou seja, nosso código estará menos acoplado.
• Código mais limpo: Visto que escrevemos códigos simples para o teste passar
• Segurança na correção de bugs
• Maior produtividade já que o desenvolvedor encontra menos bugs e não desperdiça tempo com depuradores