At Funda, reliable software starts with reliable testing. But until recently, testing complex listing scenarios often depended on production data, external integrations and a fair amount of patience. QA Engineer Kateryna Podopryhora explains how our Fake Listings tool, built on Windmill, gave teams full control over their test data and significantly improved the way we test across Funda's platform.
Imagine you're testing a feature for a newly built apartment building. To verify the feature you need a project containing ten apartments: some available, some sold, one reserved, and each with the right combination of attributes. It sounds simple, until you realise you can't create that data yourself.
Instead, you have to search production for a project that already looks exactly like your test scenario. If even one apartment has the wrong status or is missing a required attribute, the whole dataset becomes unsuitable and the search starts again.
This was exactly the kind of problem we wanted to solve.
Last year our QA team started working on a project with one clear goal: improving controllability of our systems by reducing dependence on external integrations during testing.
The result was a Fake Listings solution built on top of Windmill that allows us to generate almost any listing we need in just a few clicks.
In this blog post, I’ll share why we started this initiative, how we approached it and how adopting Windmill has significantly improved the way we test listings across Funda domains.
The challenge: when test data controls your testing
If you work with listing platforms, you will know that listings rarely exist in isolation.
A single listing can depend on multiple systems and processes, including:
- external imports
- event pipelines
- downstream services
- domain-specific configurations
- asynchronous processing
Before this project, creating test listings in our test environments simply wasn't possible.
Whenever we needed to verify a specific scenario, our only option was to find an existing listing in production and import it into a test environment.
That could mean searching for something as complex as a newly built apartment project with the right hierarchy and listing statuses, or a listing that had already reached a specific point in its lifecycle. For some scenarios – such as verifying that media files were removed after a listing was archived – we even had to wait for the scheduled background job that archives eligible listings before the data was ready to be tested.
Finding the right data often became one of the most time-consuming parts of the entire testing process.
To test a feature properly, we needed listings that matched our scenario very precisely. Whether it was a specific status, a rare edge case or a complex configuration, even a small mismatch could make the data unusable. Since modifying imported listings was often not an option, we had to rely on finding a production listing that already contained everything we needed.
Once we finally found a suitable listing, we still had to:
- import it into the test environment
- wait for synchronization to complete
- verify that all required events had been processed correctly
As a result, setting up a test scenario was often slow and unpredictable. We depended on whatever data happened to exist in production at that moment, making it difficult to reproduce edge cases and reliably test specific business scenarios.
In many cases, preparing the environment took considerably longer than actual testing.
We wanted to change that.
See also: Non-functional testing at Funda: ensuring robust performance and reliability
Why controllability matters
One of the key aspects of testability is controllability: how easily you can put a system into the exact state you need for testing.
The less control you have over your test data, the harder it becomes to:
- reproduce bugs
- validate edge cases
- automate reliable tests
- test features early in development
- isolate failures
Our goal was simple: allow QA engineers and developers to create exactly the listing they need without relying on complicated external integrations.
Instead of hunting for production listings that happened to match our test scenarios, we wanted to create those scenarios ourselves by generating the required events and letting them flow naturally through the Funda ecosystem.
That idea became the foundation of our Fake Listings approach.
Windmill
During our exploration phase, we looked for a lightweight solution that would allow us to:
- build internal tooling quickly
- trigger backend workflows
- provide a simple UI for non-developers
- integrate with our existing ecosystem
- automate repetitive setup tasks
We adopted Windmill as the foundation for this solution.
Windmill allows teams to create internal tools and workflows using scripts and lightweight UI components.
For us it became the perfect way to bridge the gap between QA needs and backend event processing.
Instead of manually creating data through multiple systems, we could expose only the required inputs through a simple interface.
What we built
We created an internal Fake Listings tool for both the private and commercial housing domains (for those who only know Funda from house hunting – yes, Funda has a commercial domain too).
Over time, the tool evolved from supporting a few common testing scenarios into a flexible solution capable of generating a wide variety of listing configurations across both domains.
The main idea was straightforward:
A user defines the desired listing type and state in Windmill and the system generates the required fake events behind the scenes. Those events then travel through the same listing pipeline as real data.
From the platform’s perspective the listing behaves like a normal listing, but from a QA perspective, setup has become dramatically simpler.
How it works
The user flow is intentionally minimal.
Using the Windmill UI users can:
- create a new listing
- define listing type
- define listing status
- configure object details
- edit existing listings
- generate specific test scenarios
Once the configuration is submitted, the magic happens under the hood.
The tool generates fake events that mimic the real listing flow inside the Funda ecosystem.
These events move through the regular listing pipeline exactly like production data would.
Within seconds, the listing becomes available in the test environment.
From the user perspective, the process requires only a couple of clicks.
A practical example
Let's go back to the newly built apartment project example.
Imagine you're testing a feature that only applies to newly built projects. To verify the functionality, you need a project representing a multi-storey apartment building with several apartments underneath it. Some apartments should be available, some sold, one reserved and perhaps one needs a very specific combination of attributes to trigger the scenario you're testing.
Before Fake Listings, creating this setup wasn't an option.
As mentioned above, we had to search production for a project that already matched these conditions, import it into a test environment, wait for the data to synchronize, and verify that everything had been processed correctly. If even one apartment had the wrong status or a required attribute was missing, we had to start searching again.
With Windmill, the workflow looks very different.
We can either create a brand-new project together with all of its related listings or extend an existing project with additional listings. Through a simple UI, we define the structure and configure the attributes and statuses we need and generate the data.
Within seconds, the listings appear in the test environment after passing through the same pipeline as real data.
No searching through production. No waiting for imports. No settling for the "closest match" because it is the only data available.
Instead, we get deterministic, reproducible test data that exactly matches the scenario we want to validate.
See also: Running Playwright tests in Azure DevOps: A step-by-step guide
What has changed for QA
The biggest improvement has been speed.
While we didn't collect formal metrics, the impact was immediately visible. Creating test data changed from a process that could take anywhere from several minutes to, in some cases, hours of searching and waiting into a workflow that takes only a few clicks. Both QA engineers and developers have quickly adopted the tool because it has removed one of the biggest bottlenecks in testing: preparing the right data. Thanks to the simple Windmill interface, even non-technical colleagues, such as Product Owners, can create complex test scenarios without needing help from engineers.
But faster test setup is only part of the story.
Faster feedback loops
QA engineers can now prepare complex scenarios during feature development instead of waiting for integrations or deployments.
This allows testing to happen earlier in the development lifecycle.
Better reproducibility
Because listings are generated from controlled inputs, reproducing bugs has become much easier.
Instead of relying on “whatever data currently exists,” we can recreate the exact same scenario repeatedly.
Improved collaboration with developers
Developers can also use the tool independently.
This has reduced back-and-forth communication around test setup and made debugging much more efficient.
Easier edge-case testing
Some scenarios are extremely difficult to reproduce with real imported data.
With Fake Listings we can intentionally generate listings that target specific edge cases or business rules.
What has changed technically
One important aspect of this project is that we did not bypass the actual listing flow.
The generated fake data still goes through the same ecosystem pipeline as real listings.
That decision was intentional.
We wanted to improve controllability without losing confidence in the behaviour of the system itself.
This approach has delivered a number of benefits:
- realistic system behaviour
- reduced dependence on external integrations
- faster setup
- better isolation
- higher confidence during testing
In practice, the tool acts as a controllable entry point into the ecosystem.
Lessons learned
Building internal QA tooling has taught us a few important lessons:
QA problems are often platform problems
What started as a QA initiative has quickly proved valuable across engineering. QAs, developers and anyone investigating issues can now recreate specific scenarios quickly and reliably, without depending on existing production data.
Small internal tools can have huge impact
The final user experience is intentionally simple.
But simplifying a complicated workflow into a “2-click solution” can save enormous amounts of time across teams.
Testability should be part of system design
The easier it is to control and observe a system, the easier it becomes to build reliable software.
Projects like this reinforce the idea that testability is not only a QA concern, but an engineering concern too.
Looking ahead
While the Fake Listings tool has already transformed how we create test data manually, one of its biggest strengths is its potential for automation.
Today engineers can generate complex test scenarios in just a few clicks. The next logical step is to make those same capabilities available directly from our automated testing workflows.
Imagine an end-to-end test that doesn't depend on pre-existing data or carefully maintained test environments. Instead the test creates exactly the data it needs at runtime, executes the validation and cleans up afterwards. No assumptions, no shared state and no waiting for someone to prepare test data.
By providing a reliable and controllable way to generate listings on demand, Fake Listings opens the door to:
- more reliable end-to-end automation
- fully self-contained test scenarios
- reduced maintenance of test environments
- faster feedback loops in CI/CD pipelines
- easier validation of edge cases that were previously difficult to reproduce
As our ecosystem continues to grow, having test data available on demand becomes increasingly valuable. What started as a solution to simplify manual testing is gradually becoming a building block for more reliable and scalable test automation.
And perhaps that's the biggest lesson from this project: when you invest in controllability, automation becomes much easier to build on top of it.
Do you have a burning question for Kateryna after reading her blog? Feel free to reach out to her via email.