< Back

One YAML to Rule Them All: Frontend and Tests in Sync

Author

Muskaan Parikh

Date

31/07/2025

Share this article

HEHE, I’m back

Back at it, with YAML, React, and a clearer view on test automation. Let’s jump in.

Flashback to when I just started at b.ignited: curious, eager, and probably way too confident in my keyboard shortcuts. Koen handed me my first assignment: “Build a Playwright framework for the Test Data Generator.” How hard could it be, right?

The Test Data Generator is this neat little tool that gives testers valid, ready-to-use data IBANs, phone numbers, the works so they don’t have to dig through documentation or guess the right format. Structured inputs, minus the headaches.

This was my first time working with Playwright and proper test automation. At first, I was just hyped to watch a headless browser click through stuff. But then... I started noticing things. 

The UI built itself, so I made the tests do the same!  

The frontend was built in a smart way: based on a config file. Each input field had a clean, predictable ID. Like UI LEGO blocks. So I thought, “If the frontend can build itself from config… why can’t the tests do the same?” Spoiler: it worked.

I started writing Playwright tests that could generate selectors dynamically. The actions were straightforward enough to generalise, and it made the tests cleaner, more flexible, and easier to extend.

The YAML Masterplan

A bit later, while brainstorming with Koen, Roland, and Dorien, this idea came up:

“What if we build the entire frontend from a YAML file…

…and then use the same YAML file to drive our tests?”

At first, it sounded like one of those ideas that’s either genius or slightly unhinged. But the more we talked it through, the more it made sense.

The Test Data Generator isn’t a complex app. It takes input, applies some validation, and returns something useful. The inputs, dates, numbers, strings with constraints can all be described in YAML.

Once we read the file and map it to an object, we can reuse that across the stack. The frontend renders from it. The tests validate from it. One file. One source of truth.

How It Works (Without the Flu;)

The frontend is built in React, using Hero UI components, and everything starts with a YAML file. A human-readable configuration that defines exactly what inputs the Test Data Generator needs.

YAML serves as the single source of truth. Because it uses clear indentation and simple keyvalue pairs, it’s easy for anyone on the team whether they’re testers, product owners, or developers, to read and understand what fields will appear in the UI. This transparency means non-technical team members can contribute without getting lost in code.

The YAML file describes a list of generator objects, each specifying details like the input type, label, validation rules, and more. When the app loads, React reads this YAML and converts it into a structured list of elements. These elements are then mapped to the appropriate Hero UI components, such as text inputs, dropdowns, or toggles.

React loops through this list and renders each component dynamically based on the YAML configuration. So whenever you add a new generator or modify an existing one, the UI updates automatically without needing any code changes.

This approach makes the system highly flexible and easy to maintain since the form’s structure can be changed just by updating the YAML. At the same time, it ensures transparency and collaboration across the team.

On the testing side, Playwright uses the same YAML file to understand the structure of the UI. It generates selectors dynamically based on the consistent IDs and fields defined in the YAML and runs through the test flows without any hardcoded values or duplicated logic.

The result is an elegant, synchronized system where the UI and tests share a single, humanreadable blueprint. This keeps everything consistent, reduces errors, and speeds up development.

Still Figuring It Out (And That’s Fine)

This project reminded me that automation doesn’t have to be complex to be powerful. Sometimes a good idea starts with “wait… but what if?” and turns into something surprisingly robust.

I’ve learned that sharing structure across layers; UI and test makes things not just easier to build, but easier to maintain. YAML and I may still argue about indentation from time to time, but we’re on good terms now.

So yeah. Still curious, still slightly chaotic, and still having a great time figuring it all out.

Happy developing and testing!