Right now, I’m working with one of X-Team’s partners to help them take their architecture and development stack to the next level.
One of our tasks is to provide a scalable testing environment for a number of projects which are currently under heavy development. You can think about it as an ecosystem containing multiple products sharing similar objects from the same business domain. It was only natural to model our testing environment in the same way, sharing the testing data across different specifications.
The challenges with testing data
How can we maintain test data which would reflect an actual production environment (both in terms of complexity and numbers)? The three most prominent challenges are:
- Sharing the same data structures across different testing approaches (BDD, E2E, Unit testing, Integration testing, Functional testing). Name it and you can probably test it.
- Making data random. There are times when our “John Doe” user is not enough to test border cases.
- Making generated data grow in numbers. When testing maps, listings, or grids, generating each object by hand is too time consuming; we need to get them in bulk.
Approaching generation and scaling
Addressing the first challenge, sharing the same data structure, is rather obvious: we need a common repository for objects. Maintaining folders with files containing JSON objects will suffice for most usecases.
When it comes to the second point – randomness – we can call the mighty Faker.js to the rescue. This small library lets you generate objects with randomized fields. Feel free to use predefined generators, such as names, emails, addresses, card numbers or, when you need something fancier, create your own generators.
We addressed the third point, by introducing a separate tool able to generate large numbers of randomised objects on demand: The Fixture Factory. It is a node package based on Faker.js syntax which provides you with a way to register object blueprints and generate massive numbers of randomised data based on them. Let’s see it in action.
Generating a simple user object.
Please note that in the example above we are using fixture factory as a global service. Blueprints can be registered and accessed from anywhere as long as we have access to fixtureFactory object (singleton). The only thing left is to generate randomized user (or ten of them).
Still – we can do better than that. Let’s use some fancier Faker.js methods (f.e. random number) and add a field based on generated fixture.
Sometimes you may need a special type of object (in this case, an admin user) for your tests.
or to postprocess generated object
The final thing worth mentioning is the ability to use fixture factory as source for single generators, rather than as a global service. So instead of registering and generating user blueprints through a Fixture Factory singleton we may get access to simple generator.
Fixture Factory is available as open source. Have fun faking.