Test des unités
Pour améliorer la qualité, la fiabilité et le niveau de performance d’applications multiplateformes, vous devez les soumettre à des tests dans des conditions d’utilisation réelle. De nombreux types de tests doivent être effectués sur une application, notamment des tests unitaires, des tests d’intégration et des tests d’interface utilisateur. Les tests unitaires sont les plus couramment réalisés et sont essentiels à la création d’applications de haute qualité.
Un test unitaire prend une petite unité d’une application, en général une méthode, l’isole du reste du code et vérifie qu’elle se comporte comme prévu. Son objectif est de vérifier que chaque unité de fonctionnalité fonctionne comme prévu, afin que les erreurs ne se propagent pas dans l’application. Il est plus efficace de détecter un bogue à l’emplacement où il se produit que d’observer indirectement son effet à un point de défaillance secondaire.
Les tests unitaires utilisent généralement le modèle « arrange-act-assert » (organiser-agir-affirmer) :
| Étape | Description |
|---|---|
| Réorganiser | Initialise les objets et définit la valeur des données passées à la méthode testée. |
| Agir | Appelle la méthode testée avec les arguments requis. |
| Assert | Vérifie que l’action de la méthode testée se comporte comme prévu. |
Ce modèle garantit que les tests unitaires sont lisibles, faciles à comprendre et cohérents.
Les tests unitaires ont le plus d’impact sur la qualité du code lorsqu’ils font partie intégrante du workflow de votre développement logiciel. Les tests unitaires peuvent servir de documentation de conception et de spécifications fonctionnelles pour une application. Dès qu’une méthode a été écrite, les tests unitaires doivent être écrits pour vérifier le comportement de la méthode en réponse aux cas de données d’entrée standard, de limite et de données d’entrée incorrectes et vérifier les hypothèses explicites ou implicites du code. Par ailleurs, avec le développement piloté par les tests, les tests unitaires sont écrits avant le code.
Important
Les tests unitaires sont très efficaces contre la régression. Autrement dit, des fonctionnalités qui fonctionnaient auparavant, mais qui ont été perturbées par une mise à jour défectueuse.
xUnit est l’infrastructure de test recommandée pour les applications .NET MAUI.
Ajouter des tests xUnit à une solution .NET MAUI
Pour ajouter des tests xUnit à votre solution MAUI .NET, effectuez l’une des opérations suivantes :
Utilisez Visual Studio pour ajouter un nouveau projet de test xUnit à votre solution.
OR
Utilisez l’interface CLI .NET pour créer un projet de test xUnit et l’ajouter à votre solution. Pour plus d’informations, consultez Tests unitaires de C# dans .NET avec dotnet test et xUnit.
Le fichier projet (.csproj) pour le projet de test xUnit est similaire à 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>
La propriété de build $(TargetFramework) spécifie l’infrastructure cible du projet de test. Il s’agit de la dernière version de .NET installée sur votre ordinateur.
Le package xunit introduit des packages enfants qui incluent l’infrastructure de test elle-même ainsi que des analyseurs Roslyn qui détectent les problèmes courants avec les tests unitaires. Les packages xunit.runner.visualstudio et Microsoft.NET.Test.Sdk sont nécessaires pour exécuter vos tests unitaires dans Visual Studio et avec la commande dotnet test. Les packages coverlet.collector permettent de collecter la couverture du code. Si vous n’avez pas l’intention de collecter la couverture du code, vous pouvez supprimer cette référence de package. Pour plus d’informations sur la couverture du code pour les tests unitaires, consultez Utiliser la couverture du code pour les tests unitaires.
Il existe deux approches principales pour structurer votre application en vue d’effectuer des tests unitaires :
- Le code sur lequel vous allez effectuer des tests unitaires se trouve dans un projet de bibliothèque de classes .NET MAUI.
- Le code sur lequel vous allez effectuer des tests unitaires se trouve dans un projet d’application .NET MAUI.
Chaque approche nécessite une configuration spécifique.
Configurer un projet de bibliothèque de classes .NET MAUI pour les tests unitaires
Avec cette approche, le code sur lequel vous allez effectuer des tests unitaires se trouve dans un projet de bibliothèque de classes .NET MAUI consommé par votre projet d’application .NET MAUI. Pour écrire des tests unitaires sur la bibliothèque de classes .NET MAUI, vous devez mettre à jour les infrastructures cibles utilisées par le projet. Pour cela, ajoutez la valeur de la propriété de build $(TargetFramework) à partir du fichier projet de test xUnit (.csproj) à la propriété de build $(TargetFrameworks) dans le fichier projet de bibliothèque de classes .NET MAUI :
<TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>
Dans cet exemple, une valeur de net8.0 a été ajoutée à la propriété de build $(TargetFrameworks) dans le fichier projet de bibliothèque de classes .NET MAUI.
Ensuite, vous devez ajouter une référence à votre projet de bibliothèque de classes .NET MAUI à partir de votre projet de test xUnit.
Configurer un projet d’application .NET MAUI pour les tests unitaires
Avec cette approche, le code sur lequel vous allez effectuer des tests unitaires se trouve dans un projet d’application .NET MAUI. Pour écrire des tests unitaires sur le projet d’application .NET MAUI, vous devez mettre à jour les infrastructures cibles utilisées par le projet. Pour cela, ajoutez la valeur de la propriété de build $(TargetFramework) à partir du fichier projet de test xUnit (.csproj) à la propriété de build $(TargetFrameworks) dans le fichier projet d’application .NET MAUI :
<TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>
Dans cet exemple, une valeur de net8.0 a été ajoutée à la propriété de build $(TargetFrameworks) dans le fichier projet d’application .NET MAUI :
Vous devez également modifier votre projet d’application .NET MAUI afin qu’il ne génère pas d’exécutable pour l’infrastructure cible utilisée par le projet de test xUnit. Pour cela, ajoutez une condition à la propriété de build $(OutputType) dans le fichier projet d’application .NET MAUI :
<OutputType Condition="'$(TargetFramework)' != 'net8.0'">Exe</OutputType>
Dans cet exemple, le projet d’application .NET MAUI produit uniquement un exécutable lorsque l’infrastructure cible n’est pas net8.0.
Ensuite, vous devez ajouter une référence à votre projet d’application .NET MAUI à partir de votre projet de test xUnit.
Écrire des tests unitaires
xUnit prend en charge deux types différents de tests unitaires :
| Type de test | Attribut | Description |
|---|---|---|
| Faits | Fact |
Tests qui sont toujours true, qui testent les conditions invariantes. |
| Théories | Theory |
Tests qui sont uniquement vrais pour un jeu de données particulier. |
Les tests unitaires doivent être placés dans votre projet de test xUnit et être décorés avec l’attribut [Fact] ou [Theory]. L’exemple suivant montre des tests unitaires qui utilisent l’attribut [Fact] :
namespace MyUnitTests
{
public class MyTests
{
[Fact]
public void PassingTest()
{
Assert.AreEqual(4, 2+2);
}
[Fact]
public void FailingTest()
{
Assert.AreEqual(5, 2+2);
}
}
}
Dans cet exemple, les tests représentent intentionnellement un test réussi et un test ayant échoué.
L’exemple suivant montre des tests unitaires utilisant l’attribut [Theory] :
namespace MyUnitTests
{
public class MyTests
{
[Theory]
[InlineData(3)]
[InlineData(4)]
[InlineData(5)]
public void MyTheoryTest(int value)
{
Assert.True(value % 2 == 1);
}
}
}
Dans cet exemple, même s’il n’existe qu’une seule méthode de test, il existe en fait trois tests puisque la théorie est exécutée une fois pour chaque élément de données.
Conseil
Testez une opération avec chaque test unitaire. À mesure que la complexité d’un test augmente, la vérification de ce test est plus difficile. En limitant un test unitaire à un seul sujet de préoccupation, vous pouvez vous assurer que vos tests sont reproductibles, qu’ils sont isolés et qu’ils ont un temps d’exécution plus court. Pour plus d’informations, consultez Bonnes pratiques relatives aux tests unitaires.
Exécuter des tests unitaires
Vous pouvez exécuter des tests unitaires dans l’Explorateur de tests dans Visual Studio ou avec la commande dotnet test. Pour obtenir des informations sur l’Explorateur de tests, consultez Exécuter des tests unitaires avec l’Explorateur de tests. Pour obtenir des informations sur la commande dotnet test, consultez Tests unitaires C# dans .NET avec dotnet test et xUnit et dotnet test.
Exécuter des tests unitaires à l’aide d’exécuteurs d’appareils
Vous pouvez également exécuter des tests unitaires sur un appareil avec un exécuteur d’appareil. Un exécuteur d’appareil est une application Test Runner qui fournit un interpréteur de commandes d’exécuteur visuel et des crochets à exécuter à partir de l’interface CLI avec XHarness. Pour plus d’informations, consultez la documentation du Wiki sur les tests à l’aide d’exécuteurs d’appareil.
