Générer des tests à partir de maquettes Figma avant le code
Générez des tests à partir de maquettes Figma avant que le code n'existe : le développement piloté par les tests pour l'interface, la QA design sans sélecteurs, et des assertions qui suivent la maquette.
10 min de lecturePar l'équipe de GUI Test Studio
Pourquoi générer des tests à partir de maquettes Figma ?
Vos designers ont déjà écrit la spécification la plus précise dont dispose votre équipe.Un fichier Figma dit ce que chaque écran doit montrer : les mots de chaque bouton, les icônes, l'ordre des champs, l'écran qui vient après un clic.Pourtant, la plupart des équipes écrivent leurs tests de bout en bout des semaines plus tard, à partir de l'application terminée, et vérifient la maquette à l'œil entre-temps.
Le développement piloté par le design (design-driven development) renverse cet ordre.C'est le développement piloté par les tests où la maquette, et non le code, est la spécification d'où vient le premier test.Vous générez les tests à partir des maquettes Figma le jour où la maquette est approuvée.Le test échoue tant que la fonctionnalité n'existe pas.Il réussit le jour où le build correspond à la maquette.Dès lors, il veille à ce que le build reste fidèle à la maquette chaque fois que celle-ci ou le code change.
Cet article explique le développement piloté par les tests, pourquoi les tests de bout en bout codés ne peuvent pas être écrits en premier, ce que sont la QA design et la dérive du design, et comment GUI Test Studio, une suite de tests de bout en bout pour les applications de bureau et les applications web, transforme une maquette Figma en un test qui s'exécute.
TDD, ATDD et BDD en une minute
Ce sont trois façons d'écrire le test en premier.Elles diffèrent par ce à partir de quoi le test est écrit et par qui le lit.
| Pratique | Le test est écrit à partir de | Qui le lit |
|---|---|---|
| Développement piloté par les tests (TDD) | Un petit comportement que le code doit avoir | Les développeurs |
| Développement piloté par les tests d'acceptation (ATDD) | Les critères d'acceptation dont l'équipe a convenu avec le métier | Toute l'équipe |
| Développement piloté par le comportement (BDD) | Des scénarios en langage courant, souvent écrits sous la forme Given, When, Then avec un outil comme Cucumber | Toute l'équipe |
La boucle du TDD a trois temps.Rouge : écrire un test qui échoue, parce que le comportement n'existe pas encore.Vert : écrire juste assez de code pour le faire réussir.Refactoriser : améliorer le code pendant que le test le garde correct.
Avancer ainsi les tests dans le cycle s'appelle souvent le « shift-left testing ».Un bug trouvé avant la livraison d'une fonctionnalité coûte moins cher à corriger.Un test écrit en premier est aussi une spécification que personne ne peut mal lire.
Pourquoi ne peut-on pas écrire un test de bout en bout avant le code ?
Le TDD fonctionne bien pour les fonctions et les API.Au niveau de l'interface utilisateur, il s'arrête en général.La raison tient à la façon dont les tests de bout en bout codés trouvent les choses à l'écran.
Un test Selenium, Playwright ou Cypress trouve chaque élément par un localisateur : un identifiant, un sélecteur CSS, un XPath, un rôle et un nom.Selenium documente huit stratégies de localisation, de l'identifiant au XPath.Cypress recommande un attribut dédié, comme data-cy, sur chaque élément qu'un test touche.
Chacun d'eux est un fait qui concerne le code.Avant que le code existe, il n'y a aucun identifiant à sélectionner ni aucun attribut à viser.Les page objects, les classes qui enveloppent chaque écran pour les tests, sont écrits sur ce même balisage.
Les instantanés visuels codés partent eux aussi du build.Playwright crée ses captures d'écran de référence à la première exécution, si bien que l'image à laquelle un test se compare est l'application telle qu'elle a été développée, et non telle qu'elle a été conçue.Storybook avec Chromatic compare chaque story de composant à sa référence approuvée, ce qui détecte les changements entre deux builds.
En pratique, le test de bout en bout est donc écrit après la fonctionnalité, par quelqu'un qui regarde l'application terminée.Il vérifie alors que l'application continue de faire ce qu'elle fait aujourd'hui, que ce soit ou non ce qui a été conçu.
QA design et dérive du design
La QA design (design QA) consiste à vérifier que le build correspond à la maquette.Dans la plupart des équipes, elle se fait à l'œil après la remise des maquettes aux développeurs : un designer place la frame Figma à côté de l'application en préproduction et liste ce qui diffère.
La dérive du design (design drift) est l'écart qui se creuse entre la maquette et le produit quand personne ne vérifie.Un libellé reçoit de nouveaux mots dans le code.Une graisse de police n'est pas celle du design system.Une icône manque sur un écran.Chaque changement est petit, et ensemble ils donnent au produit un air inachevé.
Les tests de régression visuelle ne comblent pas cet écart à eux seuls.Ils comparent le build d'aujourd'hui avec un build précédent, donc un écran qui n'a jamais correspondu à sa maquette réussit à chaque fois.
Plusieurs outils passent déjà de Figma à des cas de test.L'IA générative de Testsigma écrit des scénarios et des cas de test à partir de frames Figma, une fois configurés un identifiant d'équipe Figma et un jeton d'accès.BrowserStack Test Companion lit un lien Figma collé et écrit des cas de test, ou des scripts d'automatisation dans votre framework.Applitools Eyes permet à un test automatisé d'utiliser une frame Figma comme image de référence.
Des cas de test écrits aident vraiment à planifier, mais une personne doit encore les exécuter ou les transformer en code.Un script généré, comme tout test visuel codé, atteint toujours chaque élément par un localisateur qui n'existe qu'une fois la fonctionnalité développée.Pour un panorama plus large des outils de bout en bout, voir l'étude comparative.
Comment générer des tests de bout en bout à partir d'une maquette Figma ?
Un test ne peut être écrit à partir d'une maquette que s'il n'a pas besoin du code.Il doit trouver chaque élément comme le fait une personne : par son aspect et par ce qu'il dit.
C'est ainsi que GUI Test Studio vérifie un écran.Une assertion visuelle trouve un élément à vue et le compare avec l'image que vous attendez.Une assertion de texte lit les mots à l'écran.Une maquette contient déjà chaque image et chaque mot dont ces assertions ont besoin.
| Ce que contient la maquette Figma | Ce que le test reçoit |
|---|---|
| Chaque écran | Une image de référence de l'écran |
| Les mots d'un libellé, d'un titre ou d'un bouton | Une assertion de texte qui attend ces mots |
| Une valeur qui change, comme une date ou un montant | Une assertion de texte dynamique qui attend une valeur du même type |
| Une icône, un logo ou une image | Une assertion visuelle qui cherche cette image |
| Les sections d'un écran, comme son en-tête ou son formulaire | Une assertion de groupe par section, qui peut aussi vérifier l'agencement |
| Les liens d'un parcours de prototype | Les clics qui mènent d'un écran au suivant |
Conception
Les écrans Figma approuvés
Rouge
Le test échoue : la fonctionnalité n'existe pas encore
Développement
Un développeur ou un agent de programmation IA écrit la fonctionnalité
Vert
Le build correspond à la maquette
Le développement piloté par les tests pour l'interface, étape par étape
- 1
Générer le test à partir de la maquette approuvée
Le jour où la maquette est approuvée, importez-la.Le test décrit désormais l'écran tel qu'il a été conçu, avant que quiconque n'écrive la fonctionnalité.
- 2
Le regarder échouer : c'est l'étape rouge
Exécutez-le sur l'application d'aujourd'hui.Le nouvel écran n'y est pas, donc ses assertions échouent.Le rouge est voulu : le test est la liste du travail qui reste à faire.
- 3
Développer jusqu'à ce qu'il passe au vert
Un développeur, ou un agent de programmation IA, développe la fonctionnalité.Votre pipeline exécute le test à chaque build avec gtr-cli.Le rapport de confiance dit, élément par élément, ce qui correspond déjà à la maquette et ce qui n'y correspond pas.
- 4
Accepter une fois l'apparence réelle
Une maquette et un écran réel correspondent rarement au pixel près, parce que les polices s'affichent un peu différemment.Après la première exécution réelle, acceptez une fois l'apparence obtenue depuis le rapport de confiance.Dès lors, le test compare avec l'écran réel.Voir Quand l'application change volontairement.
- 5
Refactoriser avec le test comme garde-fou
Changez le style de l'application, refactorisez-la, changez son framework.Le test ne lit pas votre code, donc il continue de réussir tant que l'écran reste correct.Il échoue quand un utilisateur verrait une différence.
Importer depuis Figma : le test avant la fonctionnalité
GUI Test Studio fait tout cela avec Importer depuis Figma.Un petit plugin s'exécute dans Figma et sauvegarde votre maquette en un seul fichier, un paquet de maquette.GUI Test Studio récupère ce fichier.Il n'y a aucun compte Figma à connecter ni aucun jeton d'accès à créer, et rien n'est envoyé nulle part.
Le plugin est installé avec GUI Test Studio.Vous l'ajoutez une seule fois dans l'application de bureau de Figma, sous Plugins, Development, Import plugin from manifest....
Dans GUI Test Studio, choisissez Fichier, Importer depuis Figma..., et la fenêtre attend votre maquette.Dans Figma, démarrez le plugin et cochez les écrans que vous voulez, ou choisissez un parcours de prototype.Les écrans du parcours arrivent alors dans l'ordre, avec les clics qui mènent de l'un au suivant.Laissez le fichier exporté dans votre dossier Téléchargements : GUI Test Studio surveille ce dossier et ouvre la maquette en une seconde ou deux.
La revue montre chaque écran avec un cadre autour de chaque élément, et dit quelle assertion chacun reçoit.Un texte n'est vérifié comme texte que s'il se lit vraiment sur l'image.Les mots trop petits ou trop pâles reçoivent à la place une assertion visuelle, et la liste dit pourquoi.Les longs paragraphes et les grandes photos sont listés mais non cochés, parce que c'est en général du contenu d'exemple.
Cliquez sur Importer, et tout arrive sous la forme d'un seul scénario portant le nom de votre maquette.Chaque écran devient une image sur la piste Référence visuelle.Ses assertions vont sur la piste Assertion, groupées par section.Pour un parcours de prototype, le clic qui mène à l'écran suivant est dirigé sur le bouton d'où part le lien dans la maquette.
Une maquette ne dit pas où se tiendra la fenêtre de l'application, donc ces assertions recherchent sur tout l'écran.Elles comparent avec une rigueur souple, si bien que les petites différences de rendu entre une maquette et un écran réel sont tolérées, alors qu'un élément manquant ou un mot changé fait toujours échouer l'assertion.
Votre designer termine le parcours « Sign in » : Login, puis Dashboard, puis Settings.Vous importez le parcours et vous obtenez trois images, le clic sur Sign in, le clic sur la roue des paramètres, et les assertions de chaque écran.Le test est prêt bien avant la fonctionnalité.Le jour où la fonctionnalité arrive en préproduction, le pipeline parcourt l'application réelle clic après clic et signale, élément par élément, si elle correspond à la maquette.
Quand la maquette change : Synchroniser depuis Figma
Les maquettes évoluent, et un test écrit à partir d'une maquette doit évoluer avec elles.Quand la maquette change, exportez-la de nouveau depuis Figma, puis choisissez Fichier, Synchroniser depuis Figma... dans GUI Test Studio.
| Ce qui a changé dans la maquette | Ce que fait une synchronisation |
|---|---|
| Un texte se lit différemment | L'assertion attend les nouveaux mots. |
| Un élément a un aspect différent | L'assertion prend la nouvelle image. |
| Un élément a bougé ou changé de taille | L'assertion le suit, tout comme un clic dirigé sur lui. |
| Un élément n'est plus là | Son assertion est retirée. |
| Un élément est nouveau | Non coché : rien de nouveau n'est vérifié sans que vous le demandiez. |
Une assertion que vous avez modifiée vous-même n'est pas cochée non plus, si bien qu'une synchronisation n'écrase jamais votre travail sans demander.Rien n'est vérifié en arrière-plan : le test ne change que lorsque vous synchronisez.
C'est ce qui garde la dérive du design visible.Quand la maquette change et que le build ne suit pas, le test synchronisé échoue et dit quel élément diffère.
D'une maquette Figma à un test avec un assistant IA
Vous pouvez aussi confier la maquette à un assistant IA.Claude, ChatGPT ou un modèle d'IA local sur votre propre ordinateur, l'un des nôtres ou le vôtre, connecté à GUI Test Studio, crée le test à partir du paquet de maquette par le même import.Voir Créer un test depuis une consigne.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.Le test est sauvegardé, et GUI Test Studio s'ouvre dessus, prêt pour votre relecture.Il va de pair avec un agent de programmation IA : l'agent développe la fonctionnalité, et le test créé à partir de la maquette vous dit s'il a développé ce qui a été conçu.Voir Développement avec des agents IA.
Bonnes pratiques
Do
- Exporter le parcours de prototype, pour que le test parcoure les écrans dans l'ordre.
- Donner des noms clairs aux écrans et aux sections, comme Login et Header : les assertions de chaque section voyagent ensemble sous la forme d'une seule assertion de groupe qui porte leur nom.
- Exécuter le test à chaque build dès le premier jour, rouge compris.
- Accepter une fois l'apparence réelle, après la première exécution de la fonctionnalité développée.
Avoid
- Vérifier du contenu d'exemple, comme des paragraphes de remplissage et des photos de banque d'images.
- Prendre la première exécution rouge pour un test cassé : c'est la liste du travail à faire.
- Cocher chaque nouvel élément d'une synchronisation sans le regarder.
- Écrire des sélecteurs pour un écran qui n'existe pas encore.
Pas de fichier Figma ?Les images de n'importe quel outil de design, comme Sketch ou Adobe XD, fonctionnent aussi : voir Tester une fonctionnalité avant qu'elle existe.
Questions
Peut-on générer des tests à partir de maquettes Figma ?
Oui.Le plugin Figma de GUI Test Studio sauvegarde vos écrans en un seul fichier de maquette, et Importer depuis Figma le transforme en test de bout en bout : une image de référence par écran, une assertion par élément et, pour un parcours de prototype, les clics entre les écrans.Le test s'exécute sur l'application réelle une fois la fonctionnalité développée.
Comment pratiquer le développement piloté par les tests pour une interface utilisateur ?
Écrivez le test à partir de la maquette plutôt que du code.Un test qui trouve chaque élément par son aspect et par ce qu'il dit peut exister avant la fonctionnalité.Il échoue tant que la fonctionnalité manque et réussit quand le build correspond à la maquette.
Qu'est-ce que la dérive du design (design drift) ?
La dérive du design est l'écart qui se creuse entre une maquette et le produit développé à partir d'elle : des mots changés, des icônes manquantes, des polices et des espacements qui ne correspondent plus.Elle passe inaperçue quand personne ne compare le build à la maquette.
Quelle est la différence entre la QA design et les tests de régression visuelle ?
La QA design compare le build à la maquette.Les tests de régression visuelle comparent le build à un build précédent, donc ils réussissent même quand le premier build n'a jamais correspondu à la maquette.
Que devient le test quand la maquette Figma change ?
Exportez de nouveau la maquette et choisissez Synchroniser depuis Figma dans GUI Test Studio.La synchronisation liste chaque changement avec une case à cocher, ne met à jour que ce que vous laissez coché, et n'écrase jamais une assertion que vous avez modifiée vous-même.
GUI Test Studio a-t-il besoin d'accéder à mon compte Figma ?
Non.Le plugin sauvegarde un fichier de maquette sur votre ordinateur, et GUI Test Studio lit ce fichier.Il n'y a aucun compte à connecter, aucun jeton à créer, et rien n'est envoyé nulle part.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack et Applitools sont des marques de leurs propriétaires respectifs.
Prêt à enregistrer votre premier test ?
Toutes les fonctionnalités, pendant 15 jours.
Vous préférez le voir sur le type d'application que vous testez ?Réservez un appel gratuit de 30 minutes avec notre équipe.