xUnit.net: um produto testado é, certamente, de melhor qualidade

Neste artigo, demonstraremos como construir e performar seus primeiros testes unitários automatizados em .NET Core utilizando, para tanto, a ferramenta xUnit.

xUnit e testes unitários(Unit tests), o que são?

De acordo com a documentação, xUnit é uma ferramenta gratuita e de código aberto construída para o .NET Framework.

Serve para auxiliar na construção e execução de testes unitários, ou melhor, trechos de códigos construídos para testar partes específicas de determinado sistema. Geralmente executados em partes separadas da aplicação e organizados de maneiras variadas de acordo com o tipo de linguagem de programação ou o tipo de software.

Por que testar?

É fácil inferir que um produto bem testado é, por consequência, de melhor qualidade em comparação a um outro semelhante que não tenha sido. Por que um software seria diferente?

Problemas identificados no início são mais fáceis de resolver

Testes unitários são capazes de mostrar problemas não previstos durante o desenvolvimento, impedindo que perdurem e, no futuro, causem dor de cabeça durante testes de integração ou prejuízos no momento da utilização em produção, elevando, nestas situações, os custos de manutenção.

Desenvolver testes unitários não é tempo gasto, é tempo investido

Testes podem guiar o processo de desenvolvimento e tornar os procedimentos de refatoração e escalonamento mais ágeis (e até desejáveis), além de prevenir, inclusive, longas sessões de depuração (debug). O desenvolvedor pode executar os testes e encontrar, de imediato, a(s) parte(s) do sistema que, por ventura, tenham deixado de funcionar em razão de alguma alteração. Qual desenvolvedor nunca deixou de refatorar um código, adicionar uma nova funcionalidade ou atualizar uma biblioteca/dependência por não poder garantir, no futuro, a integridade de alguma aplicação?

Escrevendo os primeiros testes

Criaremos uma solução com dois projetos, sendo o primeiro deles um projeto console com dois métodos e, posteriormente, uma biblioteca que conterá os testes que irão avaliar o comportamento dos métodos criados.

Para iniciar crie o projeto console em ASP.NET Core:

Agora, crie uma classe com o nome Domínio e escreva dois métodos: um primeiro que retorne um número inteiro resultado da soma de dois fatores e outro de retorno vazio que deverá lançará uma exceção:

Logo após, referencie o método Soma dentro da classe program.cs:

Concluímos aqui nosso projeto de teste, passemos adiante para o projeto de testes.

Crie na mesma solução uma biblioteca, também em ASP.NET Core, com o nome xUnitTestEssaySampleTests e adicione os seguintes pacotes NuGet:

• Microsoft.NET.Test.Sdk
• xunit
• xunit.runner.visualstudio

Adicione como referência o projeto console(onde estão os métodos a serem testados):

Adicione também uma classe para colocar seus primeiros testes, torne-a pública, e acrescente dois métodos com o mesmo nome dos que serão testados acompanhados do sufixo Teste. Seguidamente aplique o atributo [Fact] aos métodos de teste para indicar que os mesmos devem ser executados pelo executor de testes (test runner):

Mais adiante vamos ao AAA ou Arrange-Act-Assert, um padrão de organização e formatação de testes unitários, onde:

1 – Sob o Arrange construiremos todas as pré-condições e inputs necessários para performar o método ou objeto que está sendo testado.

2 – Sob o Act colocaremos a instância e preencheremos o método ou objeto que está sendo testado.

3 – E finalmente sob o Assert devemos criar as teorias, com base nos resultados esperados do método performado no trecho Act.

No método de teste acima, estanciamos a classe que contém o método Soma que escrevemos, e inicializamos as variáveis esperadas como parâmeto, já no Act evocamos o método e passamos o resultado para uma variável que serve como parâmetro do método Equal da nossa afirmação(Assert) para verificar se o valor da mesma é igual ao valor esperado(teorizado).

Daí em diante já podemos executar, com a ajuda do Test Explorer do Visual Studio, nosso primeiro teste:

Quanto ao teste que retorna a exceção, está presente neste artigo para demonstrar que mesmo exceções são passíveis de teste. E possível testar casos como quando uma função não encontra um registro no banco de dados e retorna uma NotFoundException, ou mesmo que um outro, se for do desejo do programador, retorne uma ArgumentException e não apenas o famigerado status 500 quando receber como entrada um parâmetro inválido.

Vamos à implementação:

Agora a execução dos testes:

Mais motivos para testar

Você pode encontrar no nosso blog um artigo de um dos nossos diretores demonstrando como a automação de testes evita prejuízos no sistema financeiro.