Branching By Abstraction

Recently at a client we had a discussion as a team about our continuous integration practices. One of the goals of continuous integration is frequently pushing changes to the master branch, so that it can be integrated into the build.

But how do you do that if you need to make breaking changes? You can push to master, break everybody’s build, and earn the undying enmity of your entire team if you do this regularly. Or you can try a couple of different approaches, such as Branching by Abstraction.

I can’t claim that I thought of the concept. I read about it from Martin Fowler’s excellent article (with example) Branch By Abstraction.

The Idea

Branching by Abstraction is really a form of refactoring. One of the goals of refactoring is that you always keep your tests passing. If the change you need to make is a breaking change, you can wrap your old implementation into an interface which abstracts away the implementation details.

Once all of places in the code which used the old implementation are now using the new abstraction layer, you can change the implementation behind the abstracte interface. All of your old tests for system behavior should still pass, and you can test drive in your new features.

The Starting Point

I’ve created a simplified example of the practice using Conway’s Game of Life. This example isn’t contrived though: I was working through a complete example in C as a way of honing my skills, and realized that I had exposed my implementation for the board, and that I wanted a different implementation. I also didn’t want to break my existing tests, because it described behavior that I wanted to keep.

You can see that the initial implementation of the board is pretty simple and straight forward. There’s also a game engine for counting a cell’s neighbors. It accesses the storage of the board class directly.

While you would generally never do this in the java world (the native language of my client’s team), this is a perfectly reasonable implementation for a program written in C for an embedded microcontroller (like my original version).

There are also tests to ensure desired behavior, because I greatly prefer tested code to untested. Also, I’m lazy, so I don’t want to be performing manual tests.

The New Feature

In my original design, I was simply going to use a grid of LEDs to display the board, with cells either on or off. Storing the cell values as a boolean value makes good sense in that situation.

But at the suggestion of a colleague, I want to have a visual representation of the age of my cells. I’ll track the number of generations a cell has been alive, and represent that either via the brightness of the LED or the color, depending upon the actual implementation of the visualization. I now need to track how many generations a cell has been alive for, so an integer representation makes more sense.

The First Steps

The very first step is to define an interface which encapsulates the behavior that I care about.

In the process of writing the tests for the board, I learned that there were three behaviors that I needed:

I haven’t changed any implementations yet, and in fact no class currently implements this interface. That’s okay, I just want to get it out there into my master branch. Among other things, if another team member is implementing a board like class, I’d like this interface there to prod them to implement it rather than spinning something new.

Implement Interface

The next step is to actually implement the interface. You’ll notice that it gets its own test suite, because I don’t trust untested code. I’ve been writing code for close to 30 years, so I’m well aware that I’m an idiot and that without tests I’ll make a horrible mess of things.

I also renamed the board class to LifeBoard, partially to avoid problems (on Windows and OSX file systems and are the same file), but also because I fully intend for there to be a NeighborBoard later which will track the number of neighbors each cell has.

All of the tests still pass so this gets pushed to master.

The Transition

I begin moving the users of the board to this new interface in a series of small commits. After each change I run tests and push to master.

Hiding the Implementation

Now that all of the code is accessing the LifeBoard through the defined interface, I can Hide the implementation of the board. Tests pass and I push to master.

Implement Aging

With my interface hidden, I can now implement aging of my cells.


This bit of code probably won’t gain me fame and fortune. But it will look pretty sharp hanging on my wall once it’s expressed in hardware.

Post Script

Now that I’ve run this exercise for teams, I’ve noticed that my code doesn’t actually implement the aging feature that I want. If you look at the commit for “implement aging” above, you’ll notice that the at() function only ever returns 1 or 0, not the age of a cell. You’ll also notice that there’s no test covering this functionality.

I could hide my shame and fix the code, but I think this serves as a great example of why I prefer to write my tests first. As I said earlier in the article, I’m an idiot and I make stupid mistakes. Following my own advice, if I’d written the test first I would have caught this error.


comments powered by Disqus