Generate Tests from Figma Designs Before the Code Exists
Generate tests from Figma designs before the code exists: test-driven development for the UI, design QA without selectors, and checks that sync with the design.
10 min readBy the GUI Test Studio team
Why generate tests from Figma designs?
Your designers already wrote the most precise spec your team has.A Figma file says what every screen must show: the words on each button, the icons, the order of the fields, the screen that comes after a click.Yet most teams write their end-to-end tests weeks later, from the finished app, and check the design by eye in between.
Design-driven development turns that order around.It is test-driven development where the design, not the code, is the spec the first test comes from.You generate tests from Figma designs on the day the design is approved.The test fails while the feature does not exist.It passes the day the build matches the design.From then on, it keeps the build honest whenever the design or the code changes.
This article explains test-driven development, why coded end-to-end tests cannot be written first, what design QA and design drift are, and how GUI Test Studio, an end-to-end testing suite for desktop apps and web apps, turns a Figma design into a test that runs.
TDD, ATDD and BDD in one minute
All three are ways to write the test first.They differ in what the test is written from and who reads it.
| Practice | The test is written from | Who reads it |
|---|---|---|
| Test-driven development (TDD) | A small piece of behavior the code must have | Developers |
| Acceptance test-driven development (ATDD) | The acceptance criteria the team agreed on with the business | The whole team |
| Behavior-driven development (BDD) | Scenarios in plain words, often written as Given, When, Then with a tool such as Cucumber | The whole team |
TDD's loop has three beats.Red: write a test that fails, because the behavior is not there yet.Green: write just enough code to make it pass.Refactor: improve the code while the test keeps it correct.
Moving tests earlier like this is often called shift-left testing.A bug found before a feature ships costs less to fix.A test written first is also a spec nobody can misread.
Why can't you write an end-to-end test before the code?
TDD works well for functions and APIs.At the user interface, it usually stops.The reason is how coded end-to-end tests find things on the screen.
A Selenium, Playwright or Cypress test finds each element through a locator: an id, a CSS selector, an XPath, a role and a name.Selenium documents eight locator strategies, from the id to the XPath.Cypress recommends a dedicated attribute, such as data-cy, on every element a test touches.
Every one of those is a fact about the code.Before the code exists, there is no id to select and no attribute to point at.Page objects, the classes that wrap each screen for the tests, are written against that same markup.
Coded visual snapshots start from the build too.Playwright creates its reference screenshots on the first run, so the picture a test compares with is the app as it was built, not as it was designed.Storybook with Chromatic compares each component story with its approved baseline, which catches changes between builds.
So in practice, the end-to-end test is written after the feature, by someone looking at the finished app.It then checks that the app keeps doing what it does today, whether or not that is what was designed.
Design QA and design drift
Design QA is the check that the build matches the design.In most teams it is done by eye after the design handoff: a designer puts the Figma frame beside the staging app and lists what differs.
Design drift is the gap that grows between the design and the product when nobody checks.A label gets new words in the code.A font weight is not the one in the design system.An icon is missing on one screen.Each change is small, and together they make the product look unfinished.
Visual regression testing does not close that gap on its own.It compares today's build with an earlier build, so a screen that never matched its design passes every time.
Several tools already go from Figma to test cases.Testsigma's generative AI writes test scenarios and test cases from Figma frames, once a Figma team id and an access token are set up.BrowserStack Test Companion reads a pasted Figma link and writes test cases, or automation scripts in your framework.Applitools Eyes lets an automated test use a Figma frame as its visual baseline.
Written test cases are a real help for planning, but a person still has to run them or turn them into code.A generated script, like any coded visual test, still reaches each element through a locator that exists only once the feature is built.For a wider look at end-to-end tools, see the comparison study.
How do you generate end-to-end tests from a Figma design?
A test can be written from a design only if it does not need the code.It has to find each element the way a person does: by what it looks like and by what it says.
That is how GUI Test Studio checks a screen.A visual check finds an element by sight and compares it with the picture you expect.A text check reads the words on the screen.A design already holds every picture and every word those checks need.
| What the Figma design holds | What the test gets |
|---|---|
| Every screen | A reference picture of the screen |
| The words of a label, a title or a button | A Text Assert that waits for those words |
| A value that changes, such as a date or an amount | A Dynamic Text Assert that waits for a value of the same kind |
| An icon, a logo or a picture | A Visual Assert that looks for that picture |
| The sections of a screen, such as its header or its form | A Group Assert per section, which can also check the arrangement |
| The links of a prototype flow | The clicks that lead from one screen to the next |
Design
The approved Figma screens
Red
The test fails: the feature is not there yet
Build
A developer or an AI coding agent writes the feature
Green
The build matches the design
Test-driven development for the UI, step by step
- 1
Generate the test from the approved design
The day the design is approved, import it.The test now describes the screen as it was designed, before anyone writes the feature.
- 2
Watch it fail: that is the red step
Run it against today's app.The new screen is not there, so its checks fail.Red is the point: the test is the list of work still to do.
- 3
Build until it goes green
A developer, or an AI coding agent, builds the feature.Your pipeline runs the test on every build with gtr-cli.The Confidence Report says, element by element, what already matches the design and what does not.
- 4
Accept the real look once
A design and a real screen rarely match to the pixel, because fonts render a little differently.After the first real run, accept the actual look once from the Confidence Report.From then on, the test compares with the real thing.See When the app changes on purpose.
- 5
Refactor with the test as your guard
Restyle the app, refactor it, change its framework.The test does not read your code, so it keeps passing while the screen stays right.It fails when a user would see a difference.
Import from Figma: the test before the feature
GUI Test Studio does all of this with Import from Figma.A small plugin runs inside Figma and saves your design as one file, a design package.GUI Test Studio picks that file up.There is no Figma account to connect and no access token to create, and nothing is sent anywhere.
The plugin is installed with GUI Test Studio.You add it once in Figma's desktop app, under Plugins, Development, Import plugin from manifest....
In GUI Test Studio, choose File, Import from Figma...: the window waits for your design.In Figma, start the plugin and tick the screens you want, or pick a prototype flow.Its screens then come in order, with the clicks that lead from one to the next.Leave the exported file in your Downloads folder: GUI Test Studio is watching that folder and opens the design within a second or two.
The review shows each screen with a box around every element, and says which check each one gets.A text is checked as text only when it really reads on the picture.Words too small or too faint get a picture check instead, and the list says why.Long paragraphs and large photos are listed but not ticked, because they are usually sample content.
Click Import, and everything lands as one Scenario named after your design.Each screen becomes a picture on the Visual Reference track.Its checks go on the Assertion track, grouped by section.For a prototype flow, the click that leads to the next screen is aimed at the button the design links from.
A design does not say where the app's window will stand, so these checks search the entire screen.They compare with a relaxed strictness, so the small rendering differences between a design and a real screen are tolerated, while a missing element or a changed word still fails the check.
Your designer finishes the flow "Sign in": Login, then Dashboard, then Settings.You import the flow and get three pictures, the click on Sign in, the click on the settings gear, and the checks of each screen.The test is ready long before the feature is.The day the feature reaches staging, the pipeline clicks through the real app and reports, element by element, whether it matches the design.
When the design changes: Sync from Figma
Designs move, and a test written from a design has to move with them.When the design changes, export it again from Figma, then choose File, Sync from Figma... in GUI Test Studio.
| What changed in the design | What a sync does |
|---|---|
| A text reads differently | The check expects the new words. |
| An element looks different | The check takes the new picture. |
| An element moved or changed size | The check follows it, and so does a click aimed at it. |
| An element is no longer there | Its check is removed. |
| An element is new | Not ticked: nothing new is checked unless you ask for it. |
A check you edited yourself is not ticked either, so a sync never overwrites your work without asking.Nothing is checked in the background: the test changes only when you sync.
This is what keeps design drift visible.When the design changes and the build does not follow, the synced test fails and says which element differs.
From a Figma design to a test with an AI assistant
You can also hand the design to an AI assistant.Claude, ChatGPT or a local AI model on your own computer, one we provide or one you bring, connected to GUI Test Studio, creates the test from the design package through the same import.See Create a test from a prompt.
Create a test from C:\Designs\Login.gtsdesign, following its prototype flow.The test is saved, and GUI Test Studio opens on it, ready for you to review.It pairs well with an AI coding agent: the agent builds the feature, and the test made from the design tells you whether it built what was designed.See Development with AI agents.
Good practice
Do
- Export the prototype flow, so the test clicks through the screens in order.
- Give screens and sections clear names, such as Login and Header: the checks of each section travel as one Group Assert named after them.
- Run the test on every build from the first day, red included.
- Accept the real look once, after the first run of the built feature.
Avoid
- Checking sample content, such as placeholder paragraphs and stock photos.
- Treating the first red run as a broken test: it is the list of work to do.
- Ticking every new element in a sync without looking at it.
- Writing selectors for a screen that does not exist yet.
No Figma file?Pictures from any design tool, such as Sketch or Adobe XD, work too: see Test a feature before it exists.
Questions
Can you generate tests from Figma designs?
Yes.GUI Test Studio's Figma plugin saves your screens as one design file, and Import from Figma turns it into an end-to-end test: a reference picture per screen, a check per element and, for a prototype flow, the clicks between screens.The test runs against the real app once the feature is built.
How do you do test-driven development for a user interface?
Write the test from the design instead of the code.A test that finds each element by what it looks like and what it says can exist before the feature does.It fails while the feature is missing and passes when the build matches the design.
What is design drift?
Design drift is the gap that grows between a design and the product built from it: changed words, missing icons, fonts and spacing that no longer match.It goes unnoticed when nobody checks the build against the design.
What is the difference between design QA and visual regression testing?
Design QA checks the build against the design.Visual regression testing checks the build against an earlier build, so it passes even when the first build never matched the design.
What happens to the test when the Figma design changes?
Export the design again and choose Sync from Figma in GUI Test Studio.It lists every change with a tick, updates only what you keep ticked, and never overwrites a check you edited yourself.
Does GUI Test Studio need access to my Figma account?
No.The plugin saves a design file on your computer, and GUI Test Studio reads that file.There is no account to connect, no token to create, and nothing is sent anywhere.
Figma, Selenium, Playwright, Cypress, Storybook, Chromatic, Cucumber, Testsigma, BrowserStack and Applitools are trademarks of their respective owners.
Ready to record your first test?
Every feature, for 15 days.
Rather see it on the kind of app you test?Book a free 30-minute call with our team.