Nous allons nous concentrer aujourd’hui sur une des parties les plus importantes et les plus ennuyeuses d’un développement logiciel : les tests.
Les tests jouent un rôle essentiel aujourd’hui afin de vérifier qu’un développement fonctionne correctement. On peut distinguer 2 manières de réaliser des tests : manuelles et automatisées. Contrairement aux tests manuels, les tests automatisés permettent de gagner du temps, de réduire les erreurs humaines et d'assurer une couverture de test plus large et plus rigoureuse. Sur un projet de développement classique, il existe plusieurs outils permettant de mettre en place des tests automatisés, mais pour la Power Platform, c’est plus compliqué. Pourtant, Power Apps intègre nativement une fonctionnalité de tests automatisés qui mérite d’être exploitée. Ou pas ?
En bref
Pour une application canevas, Test Studio, intégré à Power Apps, enregistre ou écrit des cas de test en Power Fx et les rejoue sur l’application publiée. Pour aller plus loin, tests dans un pipeline de déploiement ou applications pilotées par modèle, Microsoft recommande désormais Playwright : Test Engine, son outil en code ouvert, est abandonné depuis avril 2026.
Test studio : la théorie
Power Apps Test Studio est une solution avec peu de code qui vous permet d’écrire, d’organiser et d’automatiser des tests pour les applications canevas
Source : Documentation Microsoft
Test studio est donc un outil intégré à Power Apps Canvas qui permet d’écrire des tests en Power Fx, le langage informatique pour Power Apps.
Lors de la création d’un test automatisé, on vient définir un cas de test. Un cas de test se compose d’une série d’instructions ou d’actions appelées étapes de test. Chaque cas de test doit avoir un résultat attendu, c’est ce qu’on appelle une assertion de test qui vaut true ou false suivant l’issue du test.
Les cas de test peuvent être regroupés pour former une suite de tests. Il peut être utile de rassembler plusieurs cas de test suivant une fonctionnalité ou une version de l’application.
Attention : vous devez être créateur ou copropriétaire de l’application pour la tester avec Test Studio.
Dans le studio, les tests automatisés se retrouvent dans une application en mode édition, sur le volet de gauche > Outils avancés > Tests.
Lorsqu’on clique sur ouvrir les tests on retrouve les différentes parties d’un test automatisé que l’on a cité plus haut :
Une fois les suite de tests écrites, vous pouvez les exécuter pour vérifier les fonctionnalités de l’application.
Quoi tester, et quand
- Les parcours critiques : ceux qui, s’ils cassent, bloquent le travail (créer une demande, la valider, l’envoyer).
- Après chaque modification : rejouer les tests avant de publier évite de casser une fonction qui marchait.
- Avec des données de test, dans un environnement de test : Test Studio écrit dans les vraies sources de données.
La pratique
Prenons un exemple d’application simple que j’ai pu créer par le passé avec Power Apps : une application de gestion de notes de frais.
Comme dans tout développement, la première étape va consister à définir ce que je vais tester par rapport à mes fonctionnalités. Ici, par exemple, nous avons les cas de test suivants :
Création de note de frais depuis l’écran d’accueil
- Je clique sur “Déclarer une nouvelle dépense”
- Je remplis le formulaire
- Je soumets ma demande
- Ma demande est visible depuis l’écran d’accueil
Historique de mes notes de frais
- Je clique sur voir l’historique
- J’accède au tableau de bord récapitulatif de mes notes de frais ayant un statut archivé
Une fois rentré dans le studio, voici à quoi ressemble un test :
On retrouve le même langage Power Fx que dans Power Apps avec quelques instructions supplémentaires comme :
- SetProperty : pour simuler une action utilisateur et forcer la valeur d’un contrôle
- Assert : teste une condition et renvoie true ou false selon le résultat pour valider ou invalider un test
Une fois les tests écrits, on peut enregistrer et publier le test. Attention quand même, au moment d’exécuter le test, on est obligé de publier l’application.
L’application s’ouvre ensuite sous forme de vidéo, et on voit les actions que l’on a programmées se réaliser à l’écran. Elle permet de se rendre compte si les instructions du test sont bonnes. Sur le côté, on peut suivre l’avancement de nos cas de test. Si tout est vert, alors cela signifie que les actions ont pu être réalisées et que les assertions sont vraies.
Une fois notre test réalisé, il est possible de déclencher d’autres actions : c’est ce que l’on voit dans Étapes supplémentaires OnTestCaseComplete.
Il est en réalité possible d’exécuter des actions au début de l’exécution des tests, à la fin de l’exécution d’un cas et à la fin de l’exécution (comme indiqué pour configurer, traiter ou envoyer les résultats à d’autres sources de données).
Cette utilisation peut être intéressante dans un contexte de CI/CD pour associer les tests automatisés au déploiement automatisé.
Une autre méthode pour créer un cas de test, plutôt que d’écrire les différentes étapes, serait d’enregistrer une succession d’étapes.
On peut ainsi naviguer sur l’écran, remplir les formulaires, pour faciliter la création des étapes de test. On peut ensuite ajouter des assertions pour compléter le cas.
Aller plus loin : Playwright, flux et déploiements
Microsoft a abandonné Test Engine en avril 2026 : sa documentation et son dépôt ne sont plus maintenus. Pour des tests en code, Microsoft recommande d’utiliser directement Playwright, sur lequel Test Engine reposait, avec ses exemples « Power Platform Playwright samples ».
Tester les flux Power Automate
Le concepteur de flux propose un mode test : on déclenche le flux à la main, ou on le rejoue avec les données d’une exécution précédente, puis on suit chaque étape. Pour une application qui appelle des flux, testez le flux seul d’abord, puis le parcours complet depuis l’application.
Brancher les tests sur les déploiements
Dans un pipeline (pipelines de la Power Platform, Azure DevOps ou GitHub Actions), l’application est déployée dans un environnement de test, les tests Playwright s’exécutent, et le passage en production attend leur résultat. Le vérificateur d’application et l’outil Monitor complètent ces tests en signalant les erreurs de formules et les lenteurs.
En résumé
Le test studio est accessible à tous, rapide et facile à mettre en place dans vos applications canevas. Embarqué lors de l’export de solution, l’url de test peut être partagé aux clients, pour une présentation de résultats ou une validation de processus métier. Néanmoins il connait quelques limites, car il manipule de la vraie donnée, n’est pas disponible sur tous les contrôles (notamment les contrôles modernes).
Ils peuvent toutefois représenter une bonne première étape pour l’industrialisation de vos projets Power Platform !
À lire aussi :
- Les fonctionnalités avancées de Power Apps
- Le citizen developer et la gouvernance du low-code
- La fonction Patch dans Power Apps
- Power Apps, c’est quoi : définition, usages et prix
Questions fréquentes
Comment tester une application Power Apps ?
Dans une application canevas, ouvrez Test Studio (Outils avancés, puis Tests), créez des cas de test en enregistrant vos actions ou en les écrivant en Power Fx avec SetProperty et Assert, publiez l’application, puis lancez les tests. Pour les tests en continu, Microsoft recommande Playwright.
Test Studio fonctionne-t-il avec les applications pilotées par modèle ?
Non, Test Studio ne sert qu’aux applications canevas. Pour les applications pilotées par modèle, Microsoft oriente vers des tests écrits avec Playwright.
Comment tester un flux Power Automate ?
Avec le mode test du concepteur : déclenchez le flux à la main ou rejouez-le avec les données d’une exécution précédente, puis vérifiez chaque étape et ses sorties. Testez ensuite le parcours complet depuis l’application qui l’appelle.
Test Engine est-il encore maintenu ?
Non. Microsoft a abandonné Test Engine en avril 2026 : sa documentation et son dépôt ne sont plus maintenus. Microsoft recommande d’écrire les tests avec Playwright.
