Outils de test de stabilité Blazor pour les applications à l'épreuve des balles

Les tests Blazor sont peut-être le plus gros avantage potentiel du framework. Découvrez les concepts de base des tests Blazor qui vous aideront à créer des applications à toute épreuve.

Blazor est un nouveau cadre d'application Web qui promet de fournir des expériences client Web natives sans avoir besoin d'écrire du JavaScript. Les développeurs peuvent facilement créer des applications Web complètes avec le framework et les outils .NET. Beaucoup soulignent cette fondation .NET comme la force de Blazor, mais l'histoire des tests de Blazor pourrait bien être son plus grand potentiel. Dans cet article, nous discuterons des concepts de base qui font de Blazor un candidat idéal pour les tests et des outils qui prennent en charge: Unit Testing Integration Testing et Automated System Testing .

Parce que C # est un langage compilé et utilise des classes fortement typées, il a déjà beaucoup à offrir du point de vue de la stabilité du logiciel. Les erreurs triviales sont immédiatement détectées par le compilateur comme Intellisense aide à le guider. Élargissez maintenant ces fonctionnalités, ce qui profite non seulement à la logique du serveur, mais également à la logique de votre client Web et au code des composants de l'interface utilisateur. En plus de ces principes fondamentaux, nous ajouterons Tests unitaires Tests d'intégration Tests de composants Mocking et Système automatisé Tests sur l'ensemble de l'application sans changer de langue ou de méthodologie.

En ce qui concerne l'écosystème .NET, il y a beaucoup d'offres pour faire le travail. Vous trouverez ci-dessous des outils que j'ai utilisés personnellement tout au long de ma carrière et avec lesquels j'ai eu beaucoup de succès. À l'exception de bUnit, ces outils existaient avant la création de Blazor. Depuis la sortie de Blazor, ces outils ont élargi leur utilité pour inclure la nouvelle franchise .NET.

Tests unitaires

Les tests unitaires sont la première chance de s'assurer que les éléments de logique métier fonctionnent comme prévu. Les tests unitaires sont généralement exécutés par le développeur avant de valider une fonctionnalité dans une base de code plus large. Ces tests concis permettent de détecter rapidement les problèmes. Lorsqu'il est utilisé en conjonction avec le débogage, la recherche et la résolution des problèmes prend beaucoup moins de temps que si un bogue est découvert plus tard dans le processus de développement de l'application. Pour améliorer encore la productivité, il est important que le cadre de test nécessite le moins d'installation et de configuration tout en s'intégrant étroitement à l'environnement de développement.

xUnit

xUnit a une longue histoire dans le Communauté .NET et convient parfaitement à tous les projets .NET, y compris Blazor. xUnit.net est un outil de test unitaire gratuit, open source et axé sur la communauté pour .NET. Écrit par l'inventeur original de NUnit v2, xUnit.net est la dernière technologie pour les tests unitaires C #, F #, VB.NET et d'autres langages .NET.

L'un des avantages de xUnit est sa simplicité globale car le modèle xUnit est inclus dans la charge de travail de développement multiplateforme .NET Core. L'ajout d'un projet de test xUnit à votre application est aussi simple qu'un clic droit sur une solution et en choisissant Ajouter> Nouveau projet> Projet de test xUnit dans le menu de Visual Studio, comme illustré dans Figure 1 . Vous pouvez également exécuter $ dotnet new xunit à partir de la ligne de commande.

classe publique Class1 { [Fact] public void PassingTest () { Assert.Equal (4, Add (2, 2)); } [Fact] public void FailingTest () { Assert.Equal (5, Add (2, 2)); } int Ajouter (int x, int y) { retourne x + y; } }

Comme les applications Blazor utilisent .NET pour le client et le serveur, le serveur et le client partagent la logique. xUnit est idéal pour la couche partagée d'une application Blazor car le code ici a un objectif généralisé. Comme le montre la Figure 2 ci-dessous, nous pouvons référencer l'application entière à partir de notre projet xUnit pour tester le code commun.

[Fact(DisplayName = "Can validate correctly formatted email address")] public void ValidateCorrectlyFormattedEmail () { // Organiser var validEmail = "fake@domain.com"; var uut = new EmailValidator (); // Agir var isValid = uut.Validate (validEmail); // Affirmer Assert.True (isValid); }

Dans une application Web traditionnelle écrite avec un client JavaScript, cela ne serait pas possible. Au lieu de cela, un validateur et un test séparés devraient être créés pour le client JavaScript en utilisant une chaîne d'outils complètement différente. Les atouts d'une application .NET à pile complète ne se voient pas seulement dans la logique partagée – avec les tests de composants Blazor, nous pouvons également tester les composants individuels de l'interface utilisateur.

Test des composants Blazor

Les développeurs Web sont habitués au retour instantané des le navigateur fournit. De nombreux frameworks incluent même des mécanismes intégrés pour actualiser l'application en temps réel, ou «rechargement à chaud». Le rechargement à chaud est souvent utilisé pour prototyper rapidement des composants ou des fonctionnalités pour une application donnée. Si le rechargement à chaud est certainement un outil qui a sa place dans le développement Web, il est possible qu’il soit trop utilisé. Blazor n'a pas encore fourni un tel outil bien que l'un d'entre eux soit en développement . Une alternative sans doute meilleure consiste à tester les composants d'interface utilisateur. Un composant d'interface utilisateur peut être isolé, testé et répété rapidement, tout comme la logique d'application peut l'être. Grâce aux tests unitaires, nous pouvons obtenir des résultats rapides sans avoir à charger l'application, ni même le navigateur. Pour tester un composant Blazor, nous utiliserons un nouveau framework appelé bUnit, spécialement conçu à cet effet.

bUnit

bUnit est une bibliothèque de test pour les composants Blazor. Son objectif est de faciliter la rédaction de tests unitaires stables . bUnit s'appuie sur les frameworks de tests unitaires existants tels que xUnit, NUnit et MSTest, qui exécute le test des composants Blazor comme n'importe quel test unitaire normal. bUnit exécute un test en millisecondes, par rapport aux tests d'interface utilisateur basés sur le navigateur, où un test prend généralement quelques secondes.

bUnit peut configurer et définir les composants sous tests en utilisant la syntaxe C # ou Razor. bUnit inclut des méthodes pour vérifier le rendu des composants à l'aide d'un comparateur HTML sémantique. Les paramètres, les valeurs en cascade et l'injection de services dans les composants sous sont facilités grâce aux méthodes d'assistance complètes de bUnit. Même le déclenchement de gestionnaires d’événements et l’exercice des fonctions interactives d’un composant sont pris en charge par la bibliothèque.

L’ajout d’un projet de test bUnit à votre application peut être effectué de plusieurs manières. L'une des solutions les plus simples consiste à installer le modèle de projet bUnit et à créer un nouveau projet à l'aide de la ligne de commande.

 dotnet new --install bunit.template
dotnet new bunit -o 

Une fois le projet bUnit créé, nous ajouterons notre projet ou notre bibliothèque de composants comme référence.

Nous pouvons maintenant tester des composants individuels de manière isolée avec bUnit. Puisque nous connaissons déjà xUnit, nous allons continuer avec les conventions xUnit [Fact] et écrire notre premier test bUnit. Un test de composant courant consiste à s'assurer qu'un composant s'initialise correctement et rend le balisage HTML approprié. Cela peut être accompli avec la méthode RenderComponent de bUnit.

Exemple de test d'unité de composant: initialisation et rendu

Dans l'exemple suivant, nous allons tester le composant d'alerte rendu initial. Le composant doit rendre un élément div stylé avec un bouton de fermeture interne. Le HTML rendu attendu est déclaré comme la chaîne expectedMarkup. Étant donné que bUnit repose sur une «comparaison HTML sémantique», le paramètre attendu n'a pas besoin d'être une correspondance exacte, mais plutôt une correspondance équivalente HTML. Les aspects qui n'affectent pas le comportement des composants ou la représentation visuelle sont ignorés, tels que: les commentaires, les espaces blancs insignifiants, l'ordre des classes css et les attributs implicites, pour n'en nommer que quelques-uns.

 // Bibliothèque bUnit
en utilisant Bunit;
// Cadre xUnit
en utilisant Xunit;
// Bibliothèque de composants ou application Blazor
using TestableBlazor.Client;

[Fact(DisplayName = "Initial Alert renders correct markup")]
public void AlertInit ()
{
    // Rendre un composant d'alerte
    var cut = RenderComponent  ();

    // rendu HTML attendu
    chaîne attendueMarkup = @ "
    

        
             & times; 
        
    
 ";

    // Est-ce que ça correspond?
    cut.MarkupMatches (expectedMarkup);
}

Dans ce test, une instance du composant Alert est créée et le cycle de vie du composant est complètement terminé. Le balisage final du composant rendu est ensuite vérifié par rapport au balisage attendu.

Exemple de test d'unité de composant: jeu de paramètres

bUnit peut aller au-delà des tests de rendu d'initialisation et tester des sections spécifiques du balisage en fonction des paramètres du composant. Dans l'exemple suivant, nous supposerons que nous avons un composant qui a deux thèmes de couleurs distincts représentés par une classe CSS. Nous pouvons basculer le thème en définissant le paramètre IsInfo pour changer la classe CSS. L'exemple suivant rend le composant avec le paramètre défini sur true et vérifie uniquement l'attribut de classe CSS sur le composant rendu.

 [Fact(DisplayName = "Alert has info theme")]
public void AlertColor ()
{
    // Rend le composant avec IsInfo = true
    var cut = RenderComponent  (paramètres =>
                parameters.Add (p => p.IsInfo, true));

    // La valeur CSS attendue
    var attenduCss = "alerte alerte-info";

    // La valeur CSS réelle
    var actualCss = cut.Find ("div"). GetAttribute ("class");

    // Est-ce que ça correspond?
    Assert.Equal (expectedCss, actualCss);
}

Dans ce test, une instance du composant Alert est créée et le paramètre IsInfo du composant est défini sur true. Le balisage rendu est ensuite vérifié pour l'attribut class et la valeur est validée par rapport à la classe CSS attendue.

Des tests unitaires de composants simples comme ceux-ci peuvent accélérer rapidement le processus de développement. Puisque l'application et le navigateur ne sont pas impliqués, le processus est beaucoup plus rapide et précis que de charger manuellement l'application et de vérifier visuellement la sortie rendue.

Mocks

Certains composants nécessitent des dépendances externes, comme les composants liés aux données. De plus, les composants peuvent nécessiter d'autres composants, ou être assemblés dans des vues étroitement couplées comme une forme. Que nous écrivions des tests unitaires complexes ou des tests d'intégration, nous avons besoin d'une aide supplémentaire pour préparer le terrain avec des dépendances contrôlées. Au fur et à mesure que nous étendons les capacités de test de l'application Blazor, il est utile de disposer d'une bibliothèque de simulation qui fonctionne bien avec notre environnement de test.

Mocking est un processus utilisé dans les tests unitaires lorsque l'unité testée a des dépendances externes. Le but de la moquerie est d'isoler et de se concentrer sur le code testé et non sur le comportement ou l'état des dépendances externes. En se moquant, les dépendances sont remplacées par des objets de remplacement étroitement contrôlés qui simulent le comportement des réels.

Un simulacre est un substitut sophistiqué qui retournera toujours une valeur prédéterminée. Il peut également être programmé avec des attentes en termes de combien de fois chaque méthode doit être appelée, dans quel ordre et avec quelles données.

JustMock

Telerik JustMock est une bibliothèque qui peut créer un Mock avec une seule ligne de code , rendant les tests complexes faciles à organiser.

La version gratuite de Telerik JustMock peut être installée via NuGet. De plus, une version commerciale avec des fonctionnalités avancées est également disponible.

 dotnet add package JustMock --version 2020.3.1019.2

Avec la dépendance JustMock ajoutée à notre projet de test, nous pouvons rapidement commencer à se moquer des services requis par les composants.

Exemple de test d'unité de composant: services injectés moqueurs

Lors de l'utilisation ou du test des composants Blazor, c'est courant pour voir l'erreur suivante: «Il n'y a pas de service enregistré de type 'T'. Cela signifie généralement qu'un service ne s'est pas enregistré avec l'injection de dépendances. Étant donné un composant testé qui utilise l'injection de dépendances illustrée dans l'exemple suivant, le rendu d'un composant testé sans dépendance entraînera une erreur.

 @ * Component: Index.razor * @
@inject IDataService DataService
Tâche async de remplacement protégé OnInitializedAsync ()
{
    Model.Regions = attendre DataService.GetRegions ();
}
 

 // Test unitaire
var cut = RenderComponent  ();
// Erreur: il n'y a pas de service enregistré de type 'IDataService'

Dans le cas des tests unitaires de composants, nous devons encore enregistrer un service et devrions le faire avec un moyen d'isoler les résultats de ce service pour éviter les nuances dans les données non statiques qui peuvent influencer le test. En utilisant JustMock, nous pouvons terminer le test en nous moquant directement de l'interface IDataService. Dans le code de test unitaire suivant, une maquette IDataService est créée en appelant Mock.Create. Avec la maquette créée, nous pouvons ensuite utiliser JustMock pour organiser la méthode IDataService.GetRegions afin qu'elle renvoie une réponse prévisible. Une fois la maquette organisée, le service simulé est ensuite ajouté au conteneur d'injection de dépendances de bUnit.

 private void AddMockDataService ()
{
    var mockDataService = Mock.Create  ();

    Mock.Arrange (() => mockDataService.GetRegions ())
        .Retour(
            Task.FromResult (nouvelle chaîne [] {"AA", "BB", "CC", "DD"})
        );
    // Enregistrer le service avec bUnit
    Services.AddSingleton (mockDataService);
}

Avec le service disponible pour le composant, des tests unitaires peuvent maintenant être exécutés pour tester la fonctionnalité. Dans l'exemple de test suivant, le composant Index est rendu, puis la propriété Model du composant est vérifiée pour voir si elle appelle correctement le service simulé et se remplit de données et le premier élément de données est sélectionné par défaut.

 [Fact(DisplayName = "Region first item is selected on initialization.")]
public void SettingRegionSelectsFirstItem ()
{
    AddMockDataService ()
    // Rendre la page d'index
    // Le composant appelle en interne IDataService.GetRegions ()
    // et IDataService.GetTeamsByRegion ()
    var cut = RenderComponent  ();

    // Récupère la propriété Model de l'instance du composant
    var cutModel = cut.Instance.Model;

    // Notre modèle s'est-il lié?
    // La collection Regions a-t-elle été remplie?
    Assert.Collection (cutModel.Regions,
                        i => i.Contains ("AA"),
                        i => i.Contains ("BB"),
                        i => i.Contains ("CC"),
                        i => i.Contains ("DD"));

    // La première région a-t-elle été sélectionnée par défaut?
    Assert.Equal ("AA", cut.Instance.Model.SelectedRegion);
}

Une fois que chaque composant a été soigneusement testé individuellement, l'intégration entre les composants peut être testée pour s'assurer qu'ils exécutent des tâches ou des activités spécifiques.

Exemple de test d'intégration de composants: descentes en cascade

Le test des composants en tant que groupe via des tests d'intégration garantit que les fonctionnalités d'une application se comportent comme prévu et que la communication entre les unités est irréprochable. Dans l'exemple suivant, nous allons tester l'intégration entre le cycle de vie du composant, le modèle de formulaire et plusieurs composants déroulants. Dans un scénario déroulant en cascade, une liste influence les résultats d'une autre en récupérant de nouvelles données lorsque la liste principale est modifiée.

 @inject TestableBlazor.Client.Services.IDataService DataService

        

             Région 
            
             Équipe 
            
        
         Soumettre 
         Annuler 


 @code {

    [Parameter]
    public UserFormViewModel Model {get; ensemble; } = nouveau UserFormViewModel ();
    public async Task SelectedRegionChanged (valeur de chaîne)
    {
        Model.SelectedRegion = valeur;
        Model.Teams = attendre DataService.GetTeamsByRegion (Model.SelectedRegion);
        Model.SelectedTeam = Model.Teams [0];
    }

    Tâche async de remplacement protégé OnInitializedAsync ()
    {
        // init ici
        Model.Regions = attendre DataService.GetRegions ();
        attendre SelectedRegionChanged (Model.Regions [0]);
    }
}

Le test suivant vérifie que la propriété Model du composant a la valeur SelectedTeam correcte lorsque la liste déroulante principale, SelectedRegion est modifiée. Pour ce faire, JustMock fournit une sortie fiable de IDataService.GetTeamsByRegion.

 Mock.Arrange (() => mockDataService.GetTeamsByRegion (Arg.AnyString))
    .Retour(
        (string region) => Task.FromResult (
nouvelle chaîne [] {$ "Red {region}", $ "Green {region}", $ "Blue {region}"})
    );

bUnit est ensuite utilisé pour invoquer l'événement de modification de la liste déroulante simulant l'interaction de formulaire.

 [Fact(DisplayName = "Selecting a region selects the first team value.")]
Paramètre de tâche asynchroneRegionSelectsFirstTeam ()
{
    // Rendre le composant d'index
    var cut = RenderComponent  ();

    // Invoquer un changement de liste déroulante
    attendez cut.Instance.SelectedRegionChanged ("BB");

    // Le modèle est-il la bonne équipe sélectionnée?
    Assert.Equal ("Red BB", cut.Instance.Model.SelectedTeam);
}

Ce test confirme que les méthodes correctes sont invoquées sur IDataServce lorsque le formulaire est initialisé et que la liste déroulante est exercée. Il confirme également que le modèle conserve la valeur correcte de la liste déroulante enfant jusqu'à la liaison de données bidirectionnelle.

Les tests intégrés peuvent être menés par des développeurs ou des testeurs indépendants et sont généralement constitués d'une combinaison de tests fonctionnels et manuels automatisés. Les tests avec xUnit, bUnit et JustMock peuvent couvrir de nombreux tests menés par les développeurs, tandis que les tests de système automatisés peuvent bénéficier d'outils supplémentaires.

Test de système automatisé Blazor

Le test de système est une méthode de test utilisée pour évaluer le système complet et intégré. Lors du test d'une application Blazor, un test système prouve que la fonctionnalité de bout en bout du logiciel est testée, ce qui peut inclure la compatibilité entre navigateurs, l'authentification, les services en direct et bien plus encore. Concevoir de tels tests et les exécuter de manière automatisée peut sembler décourageant, mais le bon outil pour le travail peut considérablement réduire les frais généraux et les coûts.

Telerik Test Studio