Test des composants Blazor avec BUnit

Découvrez comment configurer bUnit et implémenter un test de composant Blazor interactif.

Dans le développement de logiciels modernes, les tests automatisés sont l’un des piliers d’une qualité logicielle solide. Quand il s’agit de tester logique métiernous avons tests unitaireset nous avons appris à inverser les dépendances (inversion de contrôle) et à simuler les dépendances dans les tests.

Quand il s’agit de développement d’interface utilisateurnous comptons souvent sur basé sur un navigateur essais. Ces tests sont généralement plus complexes à mettre en œuvre et beaucoup exécution plus lente car ils restituent l’intégralité du site Web ou du composant et doivent donc initialiser l’intégralité d’un moteur de navigateur.

Pour le développement de Blazor, Bunia offre une alternative intéressante. Bunia nous permet d’implémenter des tests de composants Blazor et de les exécuter en utilisant le framework de tests unitaires de notre choix (MsTest, Nunit, xUnit), similaire à un test unitaire classique dans un incroyablement rapide chemin.

Dans cet article, nous apprenons comment configurer et utiliser bUnit pour tester facilement les composants Blazor.

Tu peux accéder au code utilisé dans cet exemple sur GitHub.

Mise en place d’un projet de test bUnit

Pour cet exemple, je suppose que nous avons un Application Web Blazor basé sur le modèle de projet Blazor Web Application disponible sur .NET 8.

Nous créons un Projet de test MsTest et ajoutez-le à la solution contenant l’application Web Blazor.

Indice: Je nomme généralement mes projets de test de la même manière que le projet testé et j’ajoute un .Essais suffixe.

Ensuite, nous voulons installer le Package NuGet bUnit au projet de test. Vous pouvez utiliser NuGet Package Manager ou la commande suivante dans la console NuGet Package Manager :

dotnet add package bunit

En écrivant cet article, j’ai remarqué que le package compte déjà plus de 5 millions de téléchargements et est activement maintenu.

Indice: Même si cet exemple suppose une application Web .NET 8+ Blazor en cours de test, bUnit fonctionne à partir de .NET 5 et des versions ultérieures.

Ensuite, nous voulons ajouter un référence du projet du projet de test à l’application Web Blazor que nous souhaitons tester.

Nous devons effectuer une configuration importante pour que le projet de test puisse fonctionner correctement. Nous devons ouvrir le fichier de projet (.csproj) et réglez le SDK à Microsoft.NET.Sdk.Razor.

Le fichier projet ressemble à ceci lors de l’utilisation MsTest comme cadre de tests unitaires :

<Project Sdk="Microsoft.NET.Sdk.Razor">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>

    <IsPackable>false</IsPackable>
    <IsTestProject>true</IsTestProject>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="bunit" Version="1.30.3" />
    <PackageReference Include="coverlet.collector" Version="6.0.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
    <PackageReference Include="MSTest.TestAdapter" Version="3.1.1" />
    <PackageReference Include="MSTest.TestFramework" Version="3.1.1" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\BunitTest\BunitTest.csproj" />
  </ItemGroup>

  <ItemGroup>
    <Using Include="Microsoft.VisualStudio.TestTools.UnitTesting" />
  </ItemGroup>
</Project>

Notez le SDK spécifié sur la première ligne, le paquet de petits pains (la première référence du package) et le référence du projet au BunitTest projet (l’application Web Blazor).

Indice: Il existe également la possibilité de installer un modèle de projet bUnit et créez un projet basé sur un modèle au lieu de le configurer manuellement.

Création d’un test bUnit dans un fichier Razor

La première étape pour pouvoir écrire des tests en .rasoir fichier était de définir le projet SDK tapez pour Microsoft.NET.Sdk.Razor. Une autre étape de préparation consiste à créer un _Imports.razor fichier similaire à un vrai projet Blazor.

Dans le _Imports.razor fichier dans le projet de test, nous insérons les instructions using suivantes :

@using Microsoft.AspNetCore.Components.Forms
@using Microsoft.AspNetCore.Components.Web
@using Microsoft.JSInterop
@using Microsoft.Extensions.DependencyInjection
@using AngleSharp.Dom
@using Bunit
@using Bunit.TestDoubles
@using BunitTest.Components

Remarquez la dernière ligne où j’ajoute un utilisation de l’instruction au Components espace de noms de l’application Blazor. Dans mon cas, j’ai nommé l’application testée BunitTestcomme indiqué plus haut dans cet article.

Si vous utilisez un framework de test différent de celui MsTestvous souhaiterez peut-être également ajouter une instruction using dans le fichier _Imports.razor déposer.

bUnit nécessite un nouveau TestContext pour chaque exécution de test. Cependant, MsTest et NUnité ne créez une classe de test qu’une seule fois. Par conséquent, nous devons implémenter la classe d’assistance suivante :

using Bunit;

public abstract class BunitTestContext : TestContextWrapper
{
    [TestInitialize]
    public void Setup() => TestContext = new Bunit.TestContext();

    [TestCleanup]
    public void TearDown() => TestContext?.Dispose();
}

On peut alors utiliser le BunitTestContext classe pour définir notre Bunia des tests en .rasoir fichiers.

Indice: Lors de l’utilisation xUnitécette étape ne s’applique pas car xUnit instancie une nouvelle classe pour chaque exécution de test.

Maintenant, créons un simple MyName composant du projet Blazor avec le code suivant :

<h1>Claudio Bernasconi</h1>

C’est un composant simple qui restitue du HTML statique. Dans le projet de test, nous en ajoutons un autre .rasoir fichier nommé MyNameTest.razor et insérez la définition de test suivante :

@attribute [TestClass]
@inherits BunitTestContext
@code
{
  [TestMethod]
  public void MyNameComponentRendersCorrectly()
  {
    
    var cut = Render(@<MyName />);

    
    cut.MarkupMatches(@<h1>Claudio Bernasconi</h1>);
  }
}

C’est une base Bunia tester en utilisant MsTest. Il utilise le @attribute Directive Razor pour ajouter le spécifique à MsTest TestClass attribut à la classe de test.

Ensuite, nous héritons du BunitTestContext classe que nous avons précédemment implémentée.

Dans le @code bloc du test, nous définissons une méthode et la nommons en fonction de notre scénario de test. Dans ce cas, nous voulons vérifier que le MyName le composant s’affiche correctement. Nous utilisons le Render méthode de la Bunni emballer et fournir le MyName composant.

Nous utilisons ensuite le MarkupMatches méthode d’extension sur la variable cut (abréviation de composant sous test), qui contient une référence au rendu MyName composant. Comme argument de méthode, nous fournissons le balisage HTML attendu.

La structure du projet et le test implémenté ressemblent désormais à ceci :

Nous utilisons ensuite le Explorateur de tests dans Visual Studio ou la ligne de commande pour exécuter les tests dans le Bunit.Tests projet.

Si tout fonctionne comme prévu, vous devriez pouvoir constater une exécution réussie du test.

Sinon, bUnit fournit généralement un message d’erreur détaillé et utile qui vous conduit à la cause de l’échec de l’exécution d’un test.

Création d’un test bUnit interactif

Le premier exemple a vérifié un composant de rendu HTML statique. Dans ce deuxième exemple, nous souhaitons implémenter un test pour un composant interactif.

Considérez le composant Blazor interactif suivant. je le nomme RandomNumberGenerator et mettez-le dans le Components dossier du BunitTest projet (l’application Blazor).

<p>@Number</p>
<button @onclick="GenerateNumber">Generate</button>

@code {
    public int Number { get; set; }
    private Random _random = new Random();

    public void GenerateNumber()
    {
        Number = _random.Next(1, 99);
    }
}

Nous avons un court modèle de composant dans lequel nous restituons un nombre généré aléatoirement lorsque l’utilisateur appuie sur un bouton.

Maintenant, ajoutons un nouveau fichier de test au BunitTest.Tests projet et nommez-le RandomNumberGeneratorTest.razor avec le code suivant :

@attribute [TestClass]
@inherits BunitTestContext
@code
{
  [TestMethod]
  public void RandomNumberGenerator_RendersANumberOnClick()
  {
    
    IRenderedComponent<RandomNumberGenerator> cut = Render<RandomNumberGenerator>(@<RandomNumberGenerator />);

    
    cut.Find("button").Click();

    
    Assert.IsTrue(cut.Instance.Number >= 1 && cut.Instance.Number <= 99);
  }
}

Tout d’abord, nous utilisons la version générique du Render méthode pour fournir le type du composant Blazor testé, dans ce cas, RandomNumberGenerator.

Nous utilisons ensuite le Find méthode sur le composant rendu pour trouver le bouton et utiliser la Click méthode pour effectuer un clic sur le bouton Générer.

Nous pouvons maintenant utiliser le Instance propriété sur la variable cut pour vérifier que la valeur de la Number la propriété est comprise entre 1 et 99.

En utilisant la variante générique du Render méthode et en déclarant la variable cut de type IRenderedComponent<RandomNumberGenerator> nous avons accès à l’état du composant et pouvons vérifier sa valeur.

Ce test effleure quelque peu la surface de ce qui est possible avec Bunia.

Comment fonctionne bUnit ?

Maintenant que nous avons appris à configurer et à utiliser Bunia pour tester les composants Blazor, nous verrons comment bUnit fonctionne sous le capot.

On peut soit utiliser .cs ou .rasoir fichiers pour implémenter les tests bUnit pour les composants Blazor. L’avantage le plus important de l’utilisation d’un .rasoir fichier est que nous pouvons déclarer le balisage.

Cependant, .cs les fichiers offrent une meilleure prise en charge de l’édition pour la mise en œuvre des tests unitaires. Je choisis généralement ce qui me convient pour chaque test individuel.

Lorsque les tests sont exécutés, les composants Blazor sont rendus et ils survivent à leur cycle de viecomme lorsqu’ils s’exécutent dans une véritable application Blazor. Nous pouvons fournir des entrées et les composants peuvent produire des données, ou les deux.

La magie opère dans les bUnits TestContext taper.

Limites de bUnit

Actuellement, il y a aucune possibilité d’exécuter JavaScript à partir d’un composant testé lors de l’utilisation de bUnit. Cependant, une solution de contournement dans la documentation bUnit explique comment émuler le IJSRuntime taper.

bUnit restitue les composants testés à l’aide d’un contexte de test. Pour certains scénarios de rendu complexes, cela peut ne pas être précis. Cependant, personnellement, je n’ai pas atteint cette limite et j’ai choisi de simplifier mon composant mise en œuvre chaque fois que je rencontrais des difficultés lors des tests.

Puisque le contexte de test utilise un approche sans têtecela ne peut pas expliquer spécifique au navigateur comportement de rendu.

Une limitation à laquelle j’ai déjà été confronté est le test de composants qui ont une logique complexe dans les méthodes de cycle de vie, en particulier lorsqu’ils ont des effets secondaires. C’est l’une des raisons pour lesquelles je limiter le comportement dans les méthodes de cycle de vie autant que possible et mets l’essentiel de ma logique dans les services.

Conclusion

Nous avons appris à rendre un composant et vérifier son balisage HTML. Nous avons également appris comment accéder au état du composant et vérifier sa valeur, ainsi que comment interagir avec un composant Blazor (en cliquant sur un bouton).

Nous n’avons pu qu’effleurer la surface dans cet article d’introduction sur la mise en œuvre des tests de composants Blazor à l’aide de bUnit.

Nous pouvons faire tellement plus avec Bunia. Par exemple, nous pouvons injecter des services dans des composants testés ou transmettre des paramètres aux composants.

Je vous recommande fortement de l’essayer vous-même pour découvrir les différentes options. bUnit est un outil de ma ceinture d’outils que je ne veux pas manquer lors du développement d’applications métier à l’aide de Blazor.

Si vous souhaitez en savoir plus sur le développement de Blazor, vous pouvez regarder mon cours intensif Blazor gratuit sur YouTube. Et restez à l’écoute du blog Telerik pour en savoir plus Les bases du Blazor.