DEV Community: Alessandra Souza

Teste de Unidade

Alessandra Souza — Sun, 25 Apr 2021 19:30:32 +0000

Teste de Unidade: É o teste da menor unidade testável de um programa.

Em português é comum falar teste unitário, porém o mais correto é o termo teste de unidade. Teste unitário da a sensação que é apenas um teste, no entanto podemos criar vários cenários para testar o seu método.

Um teste de unidade precisa ser:

Rápido: Não é incomum para projetos maduros ter milhares de testes de unidade. Os testes de unidade devem levar muito pouco tempo para serem executados. Milissegundos.
Isolado: Testes de unidade são autônomos e não têm dependências de nenhum fator externo, como um sistema de arquivos ou o banco de dados. Mesmo um teste de integração, as dependências externas são resolvidas com o uso do InMemoryDataBase ou com mocks.
Repetível: A execução de um teste de unidade deve ser consistente com seus resultados, ou seja, ele sempre retornará o mesmo resultado se você não alterar nada entre execuções. Se o teste hora passa, e hora não, talvez ele esteja compartilhando estado de algum objeto.
Verificação automática: O teste deve ser capaz de detectar automaticamente se ele foi aprovado ou reprovado sem nenhuma interação humana.
Em tempo hábil: Um teste de unidade não deve levar muito tempo para ser escrito comparado com o código que está sendo testado. Se você demorar muito tempo para escrever o teste, considere um design mais estável ou um refactoring.

Como nomear os Testes?

Modelo 01:
ObjetoEmTeste_MetodoComportamentoEmTeste_ComportamentoEsperado
Ex: Pedido_AdicionarItem_DeveExibirErroSeItemJaAdicionado

Modelo 02:
MetodoEmTeste_EstadoEmTeste_ComportamentoEsperado
Ex: AdicionarItem_ItemJaExistente_DeveExibirErroSeItemJaAdicionado

Padrão AAA

O padrão AAA auxilia na organização do teste e deixa ele mais legível.

Arrange: onde é preparado os objetos para serem testados.
Act: onde fica a ação a ser executada.
Assert: onde ficam as comparações.

Evite usar os métodos de Setup e Teardown para criar objetos utilizados no teste, assim você terá:

Menos confusão ao ler os testes, uma vez que todo o código está visível dentro de cada teste;
Menos chance de configurar demais ou de menos para o teste específico;
Menos chance de compartilhar o estado entre os testes, que cria dependências indesejadas entre eles.

Evite o uso de mais de um assert no teste, pois assim você garante que não está declarando vários cenários no mesmo teste.

Uma exceção a regra é um assert sobre propriedades de um objeto.

Frameworks para teste

MsTest: Desenvolvido pela Microsoft.
nUnit: Desenvolvido e mantido pelo .Net Foundations.
xUnit: Desenvolvido pelos mesmos criadores do nUnit e é o mais recente framework para testes.

Segue comparação entre os frameworks no link.

Apesar da Microsoft ter desenvolvido o MsTest, atualmente ela recomenda o uso do xUnit.

Exemplos com xUnit

Vamos ver agora alguns exemplos de teste de unidade, usando o framework xUnit e os padrões de nomenclatura e organização dos testes.

O teste abaixo verifica se um cpf é válido.

[Fact]
public void SocialNumber_IsValid_ReturnTrueForValidValue()
{
    //Arrange          
    //Act
    var result = SocialNumber.IsValid("52812349000");

    //Assert
    Assert.True(result);
}

No xUnit para testar mais de um valor pode-se utilizar o Theory, assim seu teste fica mais limpo.

O teste a seguir verifica se cada cpf informado no InlineData é válido.

[Theory]
[InlineData("557.287.970-32")]
[InlineData("016.118.090-61")]
[InlineData("143.504.220-48")]
[InlineData("660.352.030-35")]
[InlineData("93355758019")]
[InlineData("77228802071")]
[InlineData("24780314003")]    
public void SocialNumber_IsValid_ReturnTrueForValidValues(string value)
{
    //Arrange          
    //Act
    var result = SocialNumber.IsValid(value);

    //Assert
    Assert.True(result);
}

Para finalizar, um exemplo testando exceções.

O teste a seguir, verifica se uma determinada exceção é lançada ao informar um valor nulo.

[Fact]
public void SocialNumber_Constructor_ThrowsExceptionForNullValues()
{
    //Arrange          
    //Act   
    //Assert
    var ex = Assert.Throws<ArgumentNullException>(() => SocialNumber.FromString(null));
    Assert.Equal("Value cannot be null. (Parameter 'value')", ex.Message);
}

Caso queira ver o código completo, segue o link do GitHub.

Referências

Recomendo a leitura deste artigo da Microsoft. Nada melhor do que beber a água direto da fonte.

https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices

Se quiser se aprofundar mais no assunto, também recomendo o curso "Dominando os Testes de Software" do Eduardo Pires na plataforma https://desenvolvedor.io.

Mockando Injeção de Dependência em Testes Integrados no ASP.NET 3.1

Alessandra Souza — Thu, 08 Oct 2020 17:10:30 +0000

O que é um Teste de Integração?

O teste de integração é o teste entre diferentes módulos em um sistema, testando a integração entre as unidades. Muito útil para testar middlewares, mas além disso é possível testar uma requisição completa, evitando falhas como as citadas abaixo:

Erros de interpretação: ocorre quando uma funcionalidade está implementada diferente da especificação.
Chamadas incorretas: quando existe a chamada de unidades em locais errados.
Erros de interface: quando o padrão de integração entre as unidades foi implementado erroneamente, seja a ordem, tipo ou formato de parâmetros errados.

Para este tutorial, foram feitas algumas modificações na API que o próprio modelo ASP.NET Core Web Application cria ao inicializar um novo projeto.

 [ApiController]
public class WeatherForecastController : ControllerBase
{
    private readonly IWeatherService _weatherService;
    public WeatherForecastController(IWeatherService weatherService)
    {
        _weatherService = weatherService;
    }

    [HttpGet("/report")]
    public ContentResult GetWeatherForecastReport()
    {
        return new ContentResult()
        {
            Content = _weatherService.WriteWeatherForecastReport(),
            StatusCode = 200
        };
    }
}

Criei uma camada de serviço e repositório para obter a previsão do tempo ao invés de deixar este código na controller.

Agora iremos partir para o teste de integração!

Criação de um Teste de Integração

Para criar um teste de integração é necessário criar um host e para isso utilizaremos o HostBuilder. Para saber mais sobre host e as mudanças do Asp.Net Core 3.1 para as versões anteriores, eu sugiro a leitura deste artigo. Link

var hostBuilder = new HostBuilder()
            .ConfigureWebHost(webHost =>
            {                      
                webHost.UseTestServer();
                webHost.UseEnvironment("Test");
                webHost.UseStartup<Startup>();
            });

O UseTestServer indica que iremos utilizar o TestServer.

Nota: O UseTestServer está dentro do pacote Microsoft.AspNetCore.Mvc.Testing.

Em UseEnvironment indicamos qual ambiente iremos utilizar para realizar o teste.

Por último informamos qual classe Startup iremos utilizar.

Após construir o host, precisamos inicializá-lo, e para isso utilizamos o código abaixo:

var host = hostBuilder.StartAsync();

Agora é necessário criar uma instância para este servidor em memória que acabamos de criar.

var client = host.GetTestClient();

Por fim, fazemos a chamada do endpoint.

var response = client.GetAsync("/report");

Vamos ver agora como ficou o teste completo:

[Fact]
public void TestReport()
{
    //Arrange
    var hostBuilder = new HostBuilder()
            .ConfigureWebHost(webHost =>
            {                      
                webHost.UseTestServer();
                webHost.UseEnvironment("Test");
                webHost.UseStartup<Startup>();
            });

    var host = hostBuilder.Start();
    var client = host.GetTestClient();

    // Act
    var response =  client.GetAsync("/report");
    var responseString = response.Result.Content.ReadAsStringAsync();

    // Assert
    Assert.NotNull(responseString);
}

Teste de Integração Trocando a Injeção de Dependência

Agora que você já sabe a estrutura básica de um teste de integração no Asp.Net Core 3.1, vamos aprender como trocar a injeção de dependência.

No cenário anterior, temos a controller com uma injeção de dependência para o serviço e o serviço dependia de uma interface do tipo IWeatherRepository.

public class WeatherRepository : IWeatherRepository
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

    public WeatherForecast GetWeatherForecast()
    {
        var rng = new Random();
        return  new WeatherForecast
        {
            Date = DateTime.Now,
            TemperatureC = rng.Next(-20, 55),
            Summary = Summaries[rng.Next(Summaries.Length)]
        };

    }
}

O repositório simplesmente devolvia uma previsão do tempo randômica, mas e se quisermos trocar por um repositório fake que esteja no projeto de teste para sempre nos devolver uma mesma previsão do tempo?

Para isso será necessário adicionar uma configuração a mais no construtor do host.

Na construção do host, temos acesso ao método ConfigureTestServices. Caso ele seja adicionado depois do UseStartup, nós podemos acessar o IServiceCollection que foi gerado anteriormente para criar um provedor de serviços.

webHost.ConfigureTestServices(services =>
     {
         services.SwapTransient<IWeatherRepository, FakeWeatherRepository>();
     });

Com o método abaixo, podemos buscar qual foi a implementação configurada na Startup para a interface, e realizar a troca pela implementação que quisermos.

public static void SwapTransient<TService, TImplementation>(this IServiceCollection services)
where TImplementation : class, TService
{
    if (services.Any(x => x.ServiceType == typeof(TService) && x.Lifetime == ServiceLifetime.Transient))
    {
        var serviceDescriptors = services.Where(x => x.ServiceType == typeof(TService) &&
        x.Lifetime == ServiceLifetime.Transient).ToList();
        foreach (var serviceDescriptor in serviceDescriptors)
        {
            services.Remove(serviceDescriptor);
        }
    }

    services.AddTransient(typeof(TService), typeof(TImplementation));
}

O método de teste ficou assim:

[Fact]
public void TestReportWithFixForecast()
{
    //Arrange
    var hostBuilder = new HostBuilder()
         .ConfigureWebHost(webHost =>
         {
             webHost.UseTestServer();
             webHost.UseEnvironment("Test");
             webHost.UseStartup<Startup>();
             webHost.ConfigureTestServices(services =>
             {
                 services.SwapTransient<IWeatherRepository, FakeWeatherRepository>();
             });
         });

    var host = hostBuilder.Start();
    var client = host.GetTestClient();

    // Act
    var response = client.GetAsync("/report");
    var responseString = response.Result.Content.ReadAsStringAsync();

    // Assert
    Assert.Equal("Today's weather is Warm. With temperature 73", responseString.Result);
}

Caso queira consultar o código utilizado neste artigo, é só acessar o link do repositório no GitHub.

Referências

Este artigo foi fortemente baseado em uma série de artigos do Adam Storr, indico a leitura caso tenha interesse em se aprofundar mais no assunto.

Caso queira saber mais sobre testes de integração indico a leitura desta tese.

Por fim não deixe de ler a documentação do ASP.NET Core.