Por que testar C# não é assustador, mas sim vantajoso?
\n\nSe você está apenas começando sua jornada em C# e já ouviu que "um bom desenvolvedor sempre escreve testes", mas não faz ideia de como abordar essa questão — você veio ao lugar certo. Testar código muitas vezes assusta iniciantes: parece algo complexo, que exige conhecimento profundo de arquitetura e toneladas de configurações. Na verdade, escrever testes em C# é uma habilidade que pode ser aprendida em uma noite, e os benefícios duram anos.
\n\nImagine que você montou um mecanismo complexo com milhares de peças. Você não o ligaria na potência máxima sem verificar cada componente, certo? O mesmo acontece com o programa: testes unitários C# permitem verificar cada "parafuso" do seu código separadamente, sem esperar que todo o sistema quebre em produção. Neste artigo, abordaremos testes C# do zero: desde a escolha do framework até a escrita do primeiro teste significativo. Vamos nessa!
\n\nPor onde começar os testes em C#: preparação do ambiente
\n\nAntes de escrever código, vamos garantir que você tenha tudo o que precisa. Para testar C#, você precisará de:
\n- \n
- Visual Studio 2022 (Community edition — gratuito) ou JetBrains Rider (se tiver licença). \n
- .NET SDK (versão 6, 7 ou 8 — qualquer LTS serve). \n
- Compreensão básica de POO em C#: classes, métodos, interfaces. \n
Quando o ambiente estiver pronto, crie um novo projeto. Recomendo separar o código em dois projetos: o principal (sua biblioteca ou aplicativo) e o de teste. No Visual Studio, isso é feito com o comando: File → New → Project → xUnit Test Project (.NET Core) ou NUnit Test Project. Mas vamos um pouco além e abordaremos ambas as ferramentas populares.
Escolhendo o framework: NUnit vs xUnit
\n\nNo mundo C#, existem dois principais "players" para escrever testes unitários: NUnit e xUnit. Ambos funcionam muito bem, mas há nuances:
\n\n- \n
- NUnit — clássico, vindo do Java (análogo ao JUnit). Possui atributos
[Test],[SetUp],[TearDown]. Muito intuitivo para iniciantes. \n - xUnit — framework moderno dos criadores do ASP.NET. Usa
[Fact]e[Theory]. É considerado mais "limpo" e se integra melhor com .NET Core. \n
Para iniciantes, recomendo xUnit — é mais simples, não requer atributos extras e é mais fácil de entender. Mas se sua equipe usa NUnit — sem problemas, abordaremos ambas as opções.
\n\nPrimeiro teste unitário em C#: escrevendo código
\n\nSuponha que temos uma classe calculadora simples:
\n\npublic class Calculator\n{\n public int Add(int a, int b) => a + b;\n \n public int Divide(int a, int b)\n {\n if (b == 0)\n throw new DivideByZeroException("Não é possível dividir por zero!");\n return a / b;\n }\n}\n\nAgora vamos escrever testes para esta classe. Crie um projeto de teste (xUnit) e adicione uma referência ao projeto principal.
\n\nExemplo de teste com xUnit
\n\nusing Xunit;\n\npublic class CalculatorTests\n{\n [Fact]\n public void Add_ShouldReturnSum_WhenTwoNumbers()\n {\n // Arrange\n var calculator = new Calculator();\n \n // Act\n var result = calculator.Add(3, 5);\n \n // Assert\n Assert.Equal(8, result);\n }\n \n [Fact]\n public void Divide_ShouldThrowException_WhenDivideByZero()\n {\n var calculator = new Calculator();\n \n Assert.Throws<DivideByZeroException>(() => calculator.Divide(10, 0));\n }\n}\n\nObserve a estrutura Arrange-Act-Assert (AAA). Este é o padrão ouro para escrever testes: primeiro prepare os dados, depois execute a ação, então verifique o resultado. Lembre-se deste padrão — ele o salvará do caos