Partager via

Tester les composants Razor dans ASP.NET Core Blazor

  • Article

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 8 de cet article.

Par : Egil Hansen

Le test des composants Razor est un aspect important de la publication d’applications Blazor stables et gérables.

Pour tester un composant Razor, le composant en cours de test (CUT, Component Under Test) est :

  • Rendu avec une entrée appropriée correspondant au test.
  • susceptible de faire l’objet d’interaction ou de modification, selon le type de test effectué. Par exemple, des gestionnaires d’événements peuvent être déclenchés, comme un événement onclick pour un bouton.
  • Inspecté pour rechercher des valeurs attendues. Un test réussit lorsqu’une ou plusieurs valeurs inspectées correspondent aux valeurs attendues pour le test.

Approches de test

Deux approches courantes pour le test de composants Razor sont les tests de bout en bout (E2E) et les tests unitaires :

  • Tests unitaires : les tests unitaires sont écrits avec une bibliothèque de tests unitaires qui fournit les éléments suivants :

    • Rendu des composants.
    • Inspection de la sortie et de l’état des composants.
    • Déclenchement de gestionnaires d’événements et de méthodes de cycle de vie.
    • Assertions indiquant que le comportement du composant est correct.

    bUnit est un exemple de bibliothèque qui active les tests unitaires de composants Razor.

  • Test E2E : un exécuteur de test exécute une application Blazor contenant le composant en cours de test (CUT) et automatise une instance de navigateur. L’outil de test inspecte le composant en cours de test et interagit avec lui par le biais du navigateur. Playwright pour .NET est un exemple d’infrastructure de test E2E qui peut être utilisée avec des applications Blazor.

Dans les tests unitaires, seul le composant Razor (Razor/C#) est impliqué. Les dépendances externes, telles que les services et l’interopérabilité JS, doivent être simulées. Dans le test E2E, le composant Razor et toute son infrastructure auxiliaire font partie du test, ce qui inclut CSS, JS, ainsi que les API DOM et de navigateur.

L’étendue de test décrit le niveau d’exécution des tests. L’étendue de test a généralement une influence sur la vitesse des tests. Les tests unitaires s’exécutent sur un sous-ensemble des sous-systèmes de l’application et s’exécutent généralement en quelques millisecondes. L’exécution des tests E2E, qui testent un large groupe de sous-systèmes de l’application, peut prendre plusieurs secondes.

Les tests unitaires permettent également d’accéder à l’instance du composant en cours de test (CUT), ce qui permet d’inspecter et de vérifier l’état interne du composant. Cela n’est normalement pas possible dans les tests E2E.

En ce qui concerne l’environnement du composant, les tests E2E doivent s’assurer que l’état environnemental attendu a été atteint avant le début de la vérification. Sinon, le résultat est imprévisible. Dans le test unitaire, le rendu du composant en cours de test (CUT) et le cycle de vie du test sont plus intégrés, ce qui améliore la stabilité du test.

Les tests E2E impliquent le lancement de plusieurs processus, des E/S réseau et disque, ainsi que d’autres activités de sous-système qui entraînent souvent une fiabilité médiocre des tests. Les tests unitaires sont généralement isolés de ce genre de problèmes.

Le tableau suivant récapitule les différences entre les deux approches de test.

Fonctionnalité Tests unitaires Test E2E
Étendue de test Composant Razor (Razor/C#) uniquement Component Razor (Razor/C#) avec CSS/JS
Délai d’exécution des tests Millisecondes Secondes
Accès à l’instance du composant Oui Non
Sensible à l’environnement Non Oui
Fiabilité Plus fiable Moins fiable

Choisir l’approche de test la plus appropriée

Prenez en compte le scénario lors du choix du type de test à effectuer. Certaines considérations sont décrites dans le tableau suivant.

Scénario Approche suggérée Notes
Composant sans logique d’interopérabilité JS Tests unitaires Lorsqu’il n’existe aucune dépendance à l’interopérabilité JS dans un composant Razor, le composant peut être testé sans accès à JS ou à l’API DOM. Dans ce scénario, choisir le test unitaire ne présente aucun inconvénient.
Composant avec une logique d’interopérabilité JS simple Tests unitaires Il est courant que les composants interrogent le DOM ou déclenchent des animations par le biais de l’interopérabilité JS. Le test unitaire est généralement préféré dans ce scénario, car il est simple de simuler l’interaction JS par le biais de l’interface IJSRuntime.
Composant qui dépend de code JS complexe Tests unitaires et tests JS distincts Si un composant utilise l’interopérabilité JS pour appeler une bibliothèque JS volumineuse ou complexe, mais que l’interaction entre le composant Razor et la bibliothèque JS est simple, la meilleure approche est susceptible de traiter le composant et la bibliothèque ou le code JS comme deux parties distinctes, et de les tester individuellement. Testez le composant Razor avec une bibliothèque de tests unitaires, et testez le code JS avec une bibliothèque de tests JS.
Composant avec une logique qui dépend de la manipulation JS du DOM de navigateur Test E2E Lorsque les fonctionnalités d’un composant dépendent de JS et de sa manipulation du DOM, vérifiez le code JS et le code Blazor ensemble dans un test E2E. C’est l’approche que les développeurs de l’infrastructure Blazor ont adoptée avec la logique de rendu de navigateur de Blazor, qui a du code C# et du code JS fortement couplés. Le code C# et le code JS doivent fonctionner ensemble pour restituer correctement les composants Razor dans un navigateur.
Composant qui dépend d’une bibliothèque de classes tierce avec des dépendances difficiles à simuler Test E2E Lorsque les fonctionnalités d’un composant dépendent d’une bibliothèque de classes tierce qui a des dépendances difficiles à simuler, telles que l’interopérabilité JS, le test E2E peut être la seule option pour tester le composant.

Tester des composants avec bUnit

Il n’existe aucune infrastructure de test Microsoft officielle pour Blazor, mais le projet bUnit porté par la communauté offre un moyen pratique d’effectuer un test unitaire des composants Razor.

Remarque

bUnit est une bibliothèque de tests tierce. Elle n’est pas prise en charge ou gérée par Microsoft.

bUnit fonctionne avec des infrastructures de test à usage général, telles que MSTest, NUnit et xUnit. Ces infrastructures de test donnent aux tests bUnit l’apparence de tests unitaires standard. Les tests bUnit intégrés à une infrastructure de test à usage général sont généralement exécutés avec les éléments suivants :

Remarque

Les concepts de test et les implémentations de test entre différents frameworks de test sont similaires, mais pas identiques. Pour obtenir des conseils, reportez-vous à la documentation de l’infrastructure de test.

L’exemple suivant illustre la structure d’un test bUnit sur le composant Counter dans une application basée sur un modèle de projet Blazor. Le composant Counter affiche et incrémente un compteur basé sur la sélection, par l’utilisateur, d’un bouton dans la page :

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Le test bUnit suivant vérifie que le compteur du composant en cours de test (CUT) est incrémenté correctement lorsque le bouton est sélectionné :

@code {
    [Fact]
    public void CounterShouldIncrementWhenClicked()
    {
        // Arrange
        using var ctx = new TestContext();
        var cut = ctx.Render(@<Counter />);
        var paraElm = cut.Find("p");

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

        // Assert
        var paraElmText = paraElm.TextContent;
        paraElm.MarkupMatches("Current count: 1");
    }
}

Les tests peuvent également être rédigés dans un fichier de classe C# :

public class CounterTests
{
    [Fact]
    public void CounterShouldIncrementWhenClicked()
    {
        // Arrange
        using var ctx = new TestContext();
        var cut = ctx.RenderComponent<Counter>();
        var paraElm = cut.Find("p");

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

        // Assert
        var paraElmText = paraElm.TextContent;
        paraElmText.MarkupMatches("Current count: 1");
    }
}

Les actions suivantes ont lieu à chaque étape du test :

  • Organiser : le composant Counter est rendu à l’aide de l’objet TestContext de bUnit. L’élément de paragraphe du composant en cours de test (<p>) est trouvé et affecté à paraElm. Dans la syntaxe Razor, un composant peut être transmis en tant que RenderFragment à bUnit.

  • Agir : l’élément du bouton (<button>) est localisé, puis sélectionné en appelant Click, ce qui doit incrémenter le compteur et mettre à jour le contenu de la balise du paragraphe (<p>). Le contenu de texte de l’élément de paragraphe est obtenu en appelant TextContent.

  • Déclarer : MarkupMatches est appelé sur le contenu de texte pour vérifier qu’il correspond à la chaîne attendue, qui est Current count: 1.

Remarque

La méthode assert MarkupMatches diffère d’une assertion régulière de comparaison de chaînes (par exemple Assert.Equal("Current count: 1", paraElmText);). MarkupMatches effectue une comparaison sémantique de l’entrée et de la balise HTML attendue. Une comparaison sémantique est consciente de la sémantique HTML, ce qui signifie que des éléments tels que l’espace blanc non significatif est ignoré. Il en résulte des tests plus stables. Pour plus d’informations, consultez Personnalisation de la comparaison HTML sémantique.

Ressources supplémentaires