Test d’interface utilisateur automatisé en mémoire ASP.NET Core

introduction

Dans cet article, nous examinons comment exécuter des tests d’interface utilisateur automatisés en mémoire pour une application Web ASP.NET Core à l’aide de Playwright et NUnit. L’article fournit un code de démonstration et des solutions aux problèmes rencontrés en cours de route.

Tests d’interface utilisateur automatisés

Le test automatisé de toute application Web est essentiel pour s’assurer qu’elle fonctionne correctement. Au sommet de la « pyramide des tests » se trouvent fièrement les tests d’interface utilisateur ou les tests de bout en bout, au-dessus de l’intégration et des tests unitaires. Les tests automatisés de l’interface utilisateur impliquent le lancement et le contrôle d’un navigateur pour parcourir un ensemble d’interactions qu’un utilisateur effectuerait. Des assertions sont faites pour voir si l’application Web et le navigateur se comportent comme prévu. Les navigateurs sont contrôlés par des outils de test tels que Selenium, Puppeteer ou le petit nouveau du quartier, Playwright.

Normalement, les tests sont exécutés sur une application Web déployée dans un environnement de test qui a été configuré avec la même infrastructure que l’environnement de production. Cependant, dans cet article, nous examinerons l’exécution de nos tests d’interface utilisateur sur un en mémoire instance d’une application web. En exécutant le test de cette manière, nous pouvons :

Développer des tests plus rapidement.
Reconfigurez l’application avec la configuration de test.
Détectez certaines erreurs plus tôt dans le processus de développement/test.
Exécutez toujours les tests sur un environnement déployé ultérieurement.

Avant de commencer, nous devons prendre un peu de recul.

Test d’intégration avec WebApplicationFactory

Microsoft fournit un moyen pratique d’exécuter des tests d’intégration à l’aide d’un serveur Web en mémoire appelé Serveur de test.

En utilisant le WebApplicationFactory class vous fournira un TestServer en cours d’exécution. Il nécessite un type dans l’assemblage du point d’entrée de l’application. En règle générale, les classes de démarrage ou de programme peuvent être utilisées. Les WebApplicationFactory classe fournit également un virtuel ConfigureWebHost() méthode, qui permet à l’hébergeur Web d’être manipulé. Ceci est puissant et signifie que les services peuvent être supprimés, ajoutés ou échangés. Par exemple, une base de données SQL Server peut être supprimée et remplacée par une base de données en mémoire.

Un framework de test unitaire tel que xUnit ou NUnit peut être utilisé pour écrire et exécuter les tests ciblant l’application hébergée dans le TestServer en mémoire. Lorsque les tests sont exécutés, ils utilisent un HttpClient connexion fournie par le TestServer. Les HttpClient est une classe C# et n’est pas un navigateur, ce qui signifie qu’il est un peu limité et peu pratique à utiliser.

En utilisant l’approche TestServer, nous disposons d’un serveur Web en mémoire. Non seulement cela, il fournit un moyen de remplacer la façon dont l’hébergeur Web est construit afin que nous puissions personnaliser notre application pour nos besoins de test. Cela sonne bien ! Malheureusement, lorsque vous utilisez un outil d’automatisation de navigateur, tel que Selenium ou Playwright, l’approche TestServer ne fonctionne pas tout à fait.

Modification du serveur de test pour qu’il fonctionne avec Selenium et Playwright

Après avoir lu des articles vraiment utiles de Ben Day, Bertrand Thomas et un ancien de Scott Hanselman (merci les gars !), j’ai dérivé une classe de WebApplicationFactory qui fonctionne avec des outils de test de navigateur, notamment Selenium et Playwright. Dans le projet de démonstration, c’est le AutomatedTestServerFactory classer.

L’un des principaux problèmes lors de l’utilisation d’un TestServer avec un outil de test de navigateur est que ConfigureWebHost() n’est pas appelé. Cela signifie que l’application ne peut pas être modifiée au démarrage pour utiliser une configuration de test. Dans le « traditionnel” façon d’utiliser TestServer, on nous donne un HttpClient exemple pour notre interaction demande/réponse avec le serveur. Les HttpClient l’instance est créée à l’aide du CreateClient() méthode dans WebApplicationFactory, qui dirige à son tour le ConfigureWebHost() méthode. Ainsi, la reconfiguration vraiment utile dont nous avons besoin n’est effectuée que lorsqu’un HttpClient est créé! Les outils de test du navigateur remplacent efficacement le client et sont contrôlés indépendamment du TestServer.

Pour contourner ce problème AutomatedTestServerFactory définit la configuration lorsque l’hôte Web est construit. Le travail se fait principalement selon deux méthodes CreateServer() et CreateWebHostBuilder(), qui sont appelés par le constructeur.

CreateWebHostBuilder() est appelé en premier et définit la configuration de l’hôte Web, qui est transmise en tant que paramètre de constructeur. L’environnement est également défini en option, sinon, l’environnement par défaut est la production, ce qui peut ne pas être idéal.

CreateServer() construit et démarre l’application Web et commence à écouter les demandes. Cette méthode renvoie un TestServer nul. Je n’ai vu aucun impact de cela et cela évite la création d’une instance nouvelle et différente de l’application Web.

Avec ces changements en place, nous avons une WebApplicationFactory qui crée un serveur de test en mémoire hébergeant notre application Web reconfigurée et convient à une utilisation avec Selenium ou Playwright. Super!

Utiliser Selenium ou Dramaturge

Lors du développement de ce projet, j’ai commencé à utiliser Selenium comme outil de test de navigateur, cependant, j’ai remarqué en octobre 2021, que Microsoft a mis à jour l’article de test d’intégration (voir ci-dessus) pour recommander Playwright au lieu de Selenium. J’ai donc jeté un coup d’œil, j’ai aimé, et j’ai utilisé Playwright pour le reste du projet. The Playwright est un outil de test de bout en bout relativement nouveau développé et maintenu par Microsoft.

Les raisons pour lesquelles j’ai aimé Playwright incluent sa simplification de la gestion des pilotes de navigateur, son fonctionnement avec les navigateurs Chromium, Firefox et Webkit, et la facilité d’utilisation de l’API par rapport à celle de Selenium. Par intérêt, j’ai trouvé que la migration des tests de Selenium vers Playwright était également simple !

La décision d’utiliser Playwright a également conduit à sélectionner NUnit comme lanceur de test. En règle générale, j’utilise xUnit pour les tests, mais il ne prend pas en charge l’exécution de tests Playwright en parallèle.

Configuration de Playwright sur un PC local

Pour que Playwright fonctionne, deux étapes sont nécessaires à l’aide de la console du gestionnaire de packages :

Installez Playwright CLI en tant qu’outil global.
- Exécutez la commande : install -g Microsoft.Playwright.CLI
Installez des navigateurs.
- Accédez au chemin du projet de test et exécutez la commande : playwright install

L’heure du code !

Afin de démontrer ce travail, j’ai créé une application de démonstration disponible sur GitHub. La base de code comporte trois parties, comme décrit ci-dessous.

Système des employés

Cette application est une application ASP.NET Core MVC très simple utilisant EntityFrameworkCore avec SqlClient. La seule fonctionnalité est une page d’accueil et une page renvoyant une liste d’employés. C’est assez pour nos besoins cependant! Il a un script de migration, alors n’oubliez pas de lancer update-database avant de le lancer.

Voici à quoi ressemble la page Liste des employés :

Code d’essai

Le code de test est composé de deux bibliothèques, AutomatedTesting et Employees.UITests. La bibliothèque AutomatedTesting contient le AutomatedTestServerFactory classe pour activer les tests en mémoire avec Selenium ou Playwright.

Employees.UITests est une bibliothèque de tests NUnit. Il contient une classe de base, BaseTestClass, qui est responsable de la création du serveur Web et de la transmission de la configuration requise, dans ce cas en changeant la base de données en mémoire et en ajoutant des données de test. La classe de base est décorée avec l’attribut [Parallelizable(ParallelScope.Children)] pour permettre aux tests enfants de s’exécuter en parallèle.

Les EmployeeListTests la classe hérite de BaseTestClass et se concentre sur les tests, donc le code est assez propre. Il y a trois tests, chacun est le même, mais utilisant des navigateurs différents. L’exécution du projet de test entraînera l’exécution des trois tests en parallèle. Enfin, j’ai utilisé FluentAssertions (comme je l’aime !) pour évaluer les résultats des tests.

Dans l’extrait ci-dessous, l’option de menu Employé est cliquée et des assertions sont faites sur la sortie.

J’ai commencé à retirer certaines tâches courantes dans TestHelper, comme prendre une capture d’écran et la joindre au rapport de test. Après avoir exécuté les tests, vous pouvez voir les résultats dans le journal des tests en cliquant avec le bouton droit sur un test et en ouvrant le journal.

Dans Visual Studio 2019, les résultats incluent à la fois les messages de journal et les captures d’écran.

DevOps

J’ai inclus un pipeline de build yaml pour Azure DevOps. Cette configuration répond aux exigences de Playwright, construit le code et exécute les tests sur un serveur Windows hébergé dans le cloud. Il peut également cibler une cible Windows auto-hébergée.

Problèmes résolus

Le développement de ce projet n’a pas été sans problèmes. En plus de faire fonctionner AutomatedTestServerFactory, voici les problèmes que j’ai trouvés et surmontés.

Problèmes trouvés sur le PC développeur

Numéro 1

L’application Web se lance, mais il manque le style, le JavaScript et les images. En effet, le serveur de test se lancerait dans le répertoire bin du projet de test et n’aurait pas de référence au dossier wwwroot.

Solution: Ce problème a été résolu en ajoutant une cible post-build au fichier de projet Employees.UITests. La cible copie le dossier wwwroot de manière récursive du projet Employees.UI vers le dossier Employees.UITestsbin.

Microsoft a un exemple de la façon de copier des fichiers de manière récursive pendant la construction postérieure.

Numéro 2

Microsoft.Playwright.PlaywrightException : l’exécutable n’existe pas

Solution: un ou plusieurs navigateurs sont manquants. Courir playwright install dans la console du gestionnaire de packages, mais assurez-vous de manière significative que cela est fait dans le répertoire du projet de test.

Problèmes trouvés dans Azure DevOps

Numéro 3

L’étape d’installation de Playwright Tool provoque une erreur lors de la réexécution. Les deux lignes suivantes du fichier journal indiquent le problème.

Tool 'microsoft.playwright.cli' is already installed.
Error: The process 'C:Program Filesdotnetdotnet.exe' failed with exit code 1

Solution: Au lieu d’appeler dotnet install, exécutez le dotnet update commande car cela supprime et nettoie installe l’outil.

Numéro 4

Erreur: Impossible de trouver un outil dans le fichier manifeste qui a une commande nommée « dramaturge ».

Solution: Assurez-vous que la commande d’installation du dramaturge s’exécute dans le répertoire du projet de test.

Numéro 5

Chrome hébergé dans le cloud échoue à l’exception :

Microsoft.Playwright.PlaywrightException : net :: ERR_CERT_AUTHORITY_INVALID à https://localhost:5001/

Solution: Obtenez une nouvelle instance de navigateur pour contourner ce problème en utilisant le code ci-dessous. Cela exécute efficacement les tests en mode navigation privée.

await browser.NewContextAsync(new BrowserNewContextOptions { IgnoreHTTPSErrors = true });

Numéro 6

Firefox ne navigue pas vers le site de test. Au lieu de cela, un avertissement s’affiche dans le navigateur

« Avertissement : risque de sécurité potentiel à venir ».

Solution: Firefox empêche la navigation vers un autre port sur localhost. L’avertissement nécessite une intervention manuelle, mais les paramètres peuvent être remplacés afin que le test automatisé puisse s’exécuter. Pour ce faire, définissez les capacités suivantes (ces paramètres sont brièvement traités ici) :

caps.Add("security.insecure_field_warning.contextual.enabled", false);

caps.Add("security.certerrors.permanentOverride", false);

caps.Add("network.stricttransportsecurity.preloadlist", false);

caps.Add("security.enterprise_roots.enabled", true);

Autres points

Firefox n’attend pas la fin de la requête AJAX.

En attendant le chargement d’une page qui déclenche une requête AJAX, par exemple la récupération de données lors du chargement de la page, Firefox ne semble pas attendre. Pour le résoudre, ajoutez await WaitForLoadStateAsync() après la commande pour charger la page.

Azure DevOps inclut uniquement le journal NUnit en cas d’échec du test.

NUnit offre la commodité TestContext.Out pour consigner les messages pendant les tests. Ceux-ci apparaîtront toujours à l’aide du lanceur de test dans Visual Studio 2019, mais ces messages ne sont présents dans Azure DevOps que lorsqu’un test échoue.

Conclusion

Dans cet article, nous avons exploré le code, la configuration et les pièges de l’exécution de tests d’interface utilisateur automatisés d’une application Web ASP.NET Core à l’aide de TestServer de Microsoft. Nous…