Article

Manage test dependencies with Go

September 19, 2017
Developer Tools Go
Konrad Kleine
Senior Software Engineer
Red Hat Wimplicit

Introduction

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. ;-)

Problem description

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:

  1. 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).
  2. You have to know dependencies of each individual entity.
  3. 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.

Vision

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: 

func TestListWorkItems(t *testing.T) {
    // given 10 work items
    fxt := NewTestFixture(t, WorkItems(10))
    // test that you can list all 10 of them
    // ...
}

Think of the fxt variable to have a structure similar to this one: 

type TestFixture struct {
  Identities    []*account.Identity
  Spaces        []*space.Space
  WorkItemTypes []*workitem.WorkItemType
  WorkItems     []*workitem.WorkItem
  // more entities
}

So, after the call to NewTestFixture() you can use fxt.WorkItems[idx] with idx being in the range from 0 to 9. Also, you can expect the other slices to be filled according to the dependencies that were triggered by the call to WorkItems(10). So for example, fxt.Identities fxt.Spacesand fxt.WorkItemTypes contain 1 item each. That is the least number of entities that need to exist in order to create one work item.

Additional requirements

Influence creation

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: 

NewTestFixture(t, Identities(10), WorkItems(10))

Just by coincidence, the numbers of both entities 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[0]. Here's how to address this: 

NewTestFixture(t, Identities(10), WorkItems(10, func(fxt *TestFixture, idx int){
   fxt.WorkItems[idx].AuthorID = fxt.Identities[idx].ID
})

Notice, the callback gives you access to a fully initialized work item object at index 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 creates the fxt.WorkItems[idx] object.

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 functions (e.g. Identities()and WorkItems()). 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 TopologyTree() that can only be used with the recipe function. WorkItemLinkTypes() 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: 

NewTestFixture(t, Identities(10), WorkItems(10))

NewTestFixture(t, WorkItems(10), Identities(10))

The test fixture must create the entities in the right order.

Benefits

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.

Whether you are new to Containers or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.

Last updated: September 25, 2017

Comments