Tests unitaires dans .NET MAUI

Les tests unitaires sont une étape essentielle du développement, permettant de vérifier de petites fonctionnalités spécifiques. Voici comment démarrer dans .NET MAUI.

Il existe différents types de tests dans les applications logicielles, notamment tests unitaires, tests d’intégration et tests d’interface utilisateur. Aujourd’hui, nous allons nous concentrer sur les tests unitaires, l’un des types les plus courants.

Les tests unitaires nous permettent d’examiner individuellement de petits morceaux de code, tels que des fonctions ou des méthodes, pour vérifier des fonctionnalités spécifiques. Cela vérifie que ces unités de code se comportent comme prévu et permet d’éviter que les erreurs ne se propagent dans toute l’application.

Les principaux avantages des tests unitaires sont les suivants :

• Détection précoce des erreurs
• Réduction des défauts de production
• Qualité du code améliorée

✍️ Recommandation

Lors du développement de votre application, il est recommandé d’incorporer des tests unitaires dans votre flux de travail. Ajoutez-les à votre liste « indispensable » avant de considérer qu’une fonctionnalité de code est terminée. Ces tests peuvent servir à la fois de documentation de conception et de spécifications fonctionnelles.

Intégration de xUnit dans votre solution .NET MAUI

Tout d’abord, qu’est-ce que xUnit ? xUnit est un framework de tests unitaires largement utilisé pour écrire et exécuter des tests automatisés dans des applications .NET.

Pour ajouter des tests xUnit à votre solution .NET MAUI, vous disposez de deux options :

1. Utilisez Visual Studio pour ajouter un nouveau projet de test xUnit à votre solution. Accédez à Web et console ➡️ Test ➡️ Projet de test xUnit.

2. Créez le projet xUnit à partir de la CLI .NET. Pour plus d’informations, voir Tests unitaires C# dans .NET à l’aide de dotnet test et xUnit.

Le projet créé doit inclure un fichier de projet (.csproj) qui ressemble à l’exemple suivant :

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
	    <TargetFramework>net8.0</TargetFramework>
	    <ImplicitUsings>enable</ImplicitUsings>
	    <Nullable>enable</Nullable>
	    
	    <IsPackable>false</IsPackable>
	    <IsTestProject>true</IsTestProject>
    </PropertyGroup>

    <ItemGroup>
	    <PackageReference Include="coverlet.collector" Version="6.0.0" />
	    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
	    <PackageReference Include="xunit" Version="2.5.3" />
	    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.3" />
    </ItemGroup>
    
    <ItemGroup>
	    <Using Include="Xunit" />
    </ItemGroup>

</Project>

⚠️ Un élément clé à noter dans le code est le TargetFramework propriété. Cela définit le cadre du projet et doit correspondre à la dernière version de .NET installée sur votre ordinateur.

Il existe deux approches principales pour structurer votre application pour les tests unitaires :

1. Le code que vous allez tester se trouve dans un projet de bibliothèque de classes .NET MAUI.
2. Le code que vous allez tester se trouve dans un projet d’application .NET MAUI.

Pour ajouter des tests unitaires dans un projet .NET MAUI, vous devez modifier les propriétés de build. Cela s’applique si le code que vous testez se trouve dans le projet d’application ou dans une bibliothèque de classes utilisée par l’application. Plus précisément, ajoutez le $(TargetFramework) valeur du fichier de projet de test xUnit vers le $(TargetFrameworks) propriété dans le fichier projet correspondant (soit l’application, soit la bibliothèque de classes).

Ci-dessous, je vous montre un exemple de ce à quoi cela devrait ressembler :

<TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>

Dans cet exemple, nous avons ajouté net8.0 à $(TargetFrameworks). Vous devrez ajouter une référence à votre bibliothèque de classes .NET MAUI ou à votre projet d’application à partir de votre projet de test xUnit.

Pour cibler le projet d’application .NET MAUInous avons besoin d’une étape supplémentaire. Nous devons modifier le projet d’application .NET MAUI pour l’empêcher de générer un exécutable pour le framework cible utilisé par le projet de test xUnit. Ajoutez simplement une condition au $(OutputType) build dans le fichier de projet de l’application .NET MAUI, comme suit :

<OutputType Condition="'$(TargetFramework)' != 'net8.0'">Exe</OutputType>

Écrivons des tests unitaires

xUnit prend en charge deux principaux types de tests unitaires : les faits et les théories.

Les tests unitaires doivent être placés dans votre projet de test xUnit et doivent contenir soit le [Fact] ou [Theory] attribut, en fonction du type de test que vous devez créer.

Fait

Le [Fact] L’attribut désigne une méthode comme test unitaire.

Examinons un exemple utilisant [Fact]qui désigne des tests avec des conditions invariantes, celles qui sont toujours vraies. Notre exemple comprend deux scénarios :

1. Méthode PassTest : Cette méthode démontre que 2 + 2 est égal à 4, ce qui donne un test réussi. Pour vérifier cela, nous utilisons le Assert classe, qui nous permet de vérifier si le résultat d’une opération ou l’état d’une application correspond à nos attentes de test.

2. Test d’échec : Cette méthode tente d’affirmer que 2 + 2 est égal à 5, ce qui est incorrect et entraîne un échec du test. Il utilise également le Assert classe pour vérifier le résultat.

Voyons à quoi cela ressemble dans le code :

namespace MyUnitTests
{   
    public class MyTests
    {
	    [Fact]
	    public void PassingTest()
	    {
		    Assert.AreEqual(4, 2+2);
	    }
	    
	    [Fact]
	    public void FailingTest()
	    {
		    Assert.AreEqual(5, 2+2);
	    }
    }
}

Théorie

Contrairement à [Fact]qui est un test exécuté une seule fois, le [Theory] L’attribut vous permet de tester la même logique avec plusieurs entrées, en vérifiant que le code fonctionne correctement dans divers scénarios.

Dans l’exemple ci-dessous, nous testons différents scénarios en utilisant le [InlineData] attribut pour spécifier les données transmises en tant que paramètres à la méthode de test. Nous allons créer un MyTheoryTest méthode qui accepte une valeur entière comme paramètre (le même paramètre que vous transmettez en utilisant [InlineData]).

Après avoir transmis toutes les valeurs que vous souhaitez tester, vous indiquez simplement ce que vous souhaitez confirmer : dans ce cas, si la valeur passée en paramètre est un nombre impair.

Voici à quoi cela ressemble dans le code :

namespace MyUnitTests 
{
    public class MyTests 
    {
	    [Theory] 
	    [InlineData(3)] 
	    [InlineData(4)] 
	    [InlineData(5)]
	    
	    public void MyTheoryTest(int value)  
	    { 
		    Assert.True(value % 2 == 1); 
	    } 
    }
}

Et vos tests sont terminés ! 😎

Modèle Organiser-Act-Assert (AAA)

Comme vous l’avez vu dans les exemples précédents, ces tests suivent une structure spécifique. Cette organisation est basée sur le modèle Arrange-Act-Assert.

Les tests unitaires suivent généralement ceci Organiser-Act-Assert modèle, qui rend les tests lisibles, auto-descriptifs et cohérents. Explorons leurs définitions :

Examinons l’un des exemples ci-dessus pour mieux comprendre chaque étape du code :

De cette manière simple, votre code suit le modèle Arrange-Act-Assert (AAA). 🥰

Quelques faits saillants

• Les tests unitaires sont très efficaces pour détecter les régressions, c’est-à-dire les cas où une fonctionnalité qui fonctionnait auparavant a été perturbée par une mise à jour défectueuse.
• Effectuer une opération par test unitaire. À mesure que les tests deviennent plus complexes, ils deviennent plus difficiles à vérifier. En limitant chaque test unitaire à un seul problème, vos tests sont reproductibles, isolés et exécutés plus rapidement. Pour plus d’informations sur meilleures pratiques en matière de tests unitaires, voir ici.

Comment exécuter des tests unitaires

Ces tests peuvent être exécutés de deux manières :

Conclure

C’est tout ! 🎊 Vous savez déjà par où commencer avec les tests unitaires dans vos applications .NET MAUI !

Merci d’avoir lu cet article! 💚💕

A la prochaine fois ! 🙋‍♀️

Références

Cet article était basé sur la documentation officielle :