Testes unitários em .NET com xUnit
O principal motivo de criar testes automatizados é evitar que um bug chegue até o usuário final: o seu cliente. Escrevi sobre a importância de automatizar os testes pra elevar a qualidade do software.
Neste artigo, vou exemplificar como implementar testes unitários em uma aplicação .NET com xUnit (biblioteca de testes).
O teste unitário valida partes isoladas do software. A equipe deve conversar sobre o que faz sentido no nível de unidade (método, classe ou objeto).
Disponibilizei o código da solução em um repositório do GitHub.
Estrutura da solução:
/net5-api-xunit
/WebApi
/WebApi.TestsNa pasta net5-api-xunit temos dois projetos o WebApi contém a API e o WebApi.Tests contém os testes.
Para executar a solução é necessário ter instalado no computador:
Passos para criar a solução:
- Criar uma pasta
net5-api-xunit - No Visual Studio Code (VS Code), selecione a pasta criada anteriormente e abra o terminal para executar os comandos abaixo.
- Para criar o projeto da API:
dotnet new webapi -o WebApi- Para criar o projeto dos testes com xUnit:
dotnet new xunit -o WebApi.Tests- É necessário adicionar a referência do projeto que será validado no de teste:
dotnet add ./WebApi.Tests/WebApi.Tests.csproj reference ./WebApi/WebApi.csprojFiz algumas alterações no código da API apenas a nível de organização. Os projetos estão em .NET 5.
Para executar o serviço, abra a pasta WebApi no VS Code e pressione CTRL+F5.
Copie a url no navegador: https://localhost:<porta>/WeatherForecast para retornar um JSON conforme definido no endpoint GET no controller WeatherForecastController.
Na pasta Models\WeatherForecast.cs temos o código da classe WeatherForecast:
O TemperatureF corresponde a conversão da temperatura de Celsius para Fahrenheit.
Para visualizar os testes, abra no VS Code na pasta WebApi.Tests\UnitTest.cs
O teste WeatherHasHot() valida se no array de string da Sumaries contém Hot. O ConvertCelsiusToFahrenheit valida se o valor da conversão dos graus Celsius corresponde ao Fahrenheit do parâmetro.
Os métodos devem ter o atributo [Fact] para testes sem parâmetro ou [Theory] com parâmetros. Os parâmetros do [Theory]são adicionados no atributo [InlineData]. O [Theory] pode ser usado quando um mesmo teste pode ser executado com diferentes parâmetros, com o objetivo de não repetir o código.
O Assert é um comparador usado para analisar o resultado esperado conforme o tipo (Equal, Contains, True/False e etc).
Para executar o teste, clique em Run Test, para executar o debug, clique em Debug Test.
É importante ter uma alta cobertura de código a nível de métodos, linhas e branch (possíveis caminhos que o código pode seguir if…else…). Desta forma, se uma refatoração ou correção é feita, fica mais fácil saber se algo quebrou.
Se você vai fazer uma alteração ou refatoração em um código que não tem testes, escreva testes para a funcionalidade primeiro. Por mais tentador que seja, tente criar o teste para certificar se o novo código está de acordo com o comportamento esperado.
É importante pensar em uma maneira de sempre executar todos os testes desenvolvidos antes de subir uma nova alteração para o ambiente. O ideal é adicionar os testes de alguma forma na sua pipeline de CI/CD, para caso os testes falhem não permitir que o código seja publicado para o ambiente sem as correções necessárias.
Até mais 😉!
Letícia Silva é desenvolvedora na unico.
