I’m working on the upstream fabric8-wit project of openshift.io. In this Go project, we embrace testing as best as we can in order to deliver a stable component. Testing acts as our safety net to allow for fast-paced feature development. This blog post is about our recent change in our testing strategy. It is not as boring as it might sound at first. :)
We’ve changed out the data-model quite a lot and it took us a while to realize what this means to our tests. Consider this simple data-model that is pretty close to reality:
A work item (e.g. a Bug) is part of a space (e.g. your project) and has a work item type (e.g. the template for a Bug) and an author (an Identity object).
We have repositories for each of those entities that can do basic CRUD operations. Alongside those repositories, we have tests to check that those CRUD operations do work and fail as expected.
But it was only until recently that, we had to create all the dependencies of an entity under test ourselves. For example, when we wanted to test CRUD operations on a work item, we had to manually create a space, a work item type, and an identity.
The downside is threefold:
- You’re only interested in the work item but you have to deal with things that are of no interest to you (space, work item type, and identity).
- You have to know dependencies of each individual entity.
- Consider you modify one dependency in the chain. Then you might have to touch all the places where it is being used. Especially the last point is very annoying.
In order to address the above-named issues, we were looking for a new way to write our tests. You should be able to test a work item repository CRUD-method without the need to create all dependencies. Just say that you need 10 work items and that’s it. The rest is taken care of for you automatically.
We envisioned something like this:
Think of the
fxt variable to have a structure similar to this one:
So, after the call to
you can use
idx being in the range from
Also, you can expect the other slices to be filled according to the dependencies
that were triggered by the call to
So for example,
1 item each. That is the least number of entities that need to exist in order to
create one work item.
Soon we realized that we might want to influence how each work item is created. For example, let’s say, we want 10 work items each belonging to a different user. That means, we need 10 identity objects as well:
Just by coincidence, the numbers of both entities (
10) match. Yet, the
identity objects won’t automatically be used as the author in the 10 work items.
The system shall always use the least dependency object, in this case
fxt.Identities. Here’s how to address this:
Notice, the callback gives you access to a fully initialized work item object at
idx. At this point, the identity objects are already created and can be
accessed safely from the test fixture object fxt that is passed into the
function. It is only after this anonymous function returns that the system
Request multiple objects at once
In the above example, you’ve already seen this in action. The function
NewTestFixture() obviously can handle an arbitrary number of so-called recipe
The test fixture is heavily documented in order to be easily consumable by
others. Each recipe tells you what dependencies it has and allows you to
manipulate the creation using a special form of customization function.
Flexibility within limits
We use Go’s strong type system to ensure compile-time checks on the
customization functions. Each recipe only accepts a dedicated type of function
as a specialization. That allows us to provide pre-defined functions like
that can only be used with the recipe function.
This avoids misuse of those pre-defined functions.
Order of recipe functions
The order of recipe functions must not matter. Hence, these two test fixtures are the same:
The test fixture must create the entities in the right order.
We have introduced this new test fixture in some places already. Most of the time, we cut the test code in half. On its own, this is quite an achievement in maintainability. When it comes to changing our data-model again, there’s only one place to go to. That place is inside the test fixture package.
This post was originally published here.