BalaBit Blog

Last week of September was about Code Retreat events for developers and test engineers at BalaBit. During the week we had internal Code Retreat days facilitated by Nucc and me to let everyone learn and practice the basics of Test Driven Development and handling legacy code, without the pressure of everyday work deadlines. On Saturday, September 29, BalaBit hosted the 4th event of Code Retreat Budapest (or 5th if you count last year’s Global Day of Code Retreat), with DeVill and me as facilitators. What surprises me at every Code Retreat I happen to participate in (in other words: all of them in Budapest (-:) is that you can always, always learn something new, no matter how many CR sessions and events you’ve attended.

To let participants focus on the techniuqes themselves, the job at a Code Retreat is always to implement the business logic of Conway’s Game of Life. There are 45 minutes long sessions during the day in which participants have to work in pairs, followed by short retrospective meetings and selection of a new pair for the next session. And of course, the code is deleted at the end of every session so the new one can be a green field project again. The problem usually becomes well-known by the second or third session, that’s when intensive learning can begin by introducing new constraints and concepts in every session.

Free hand session

The first session is typically free hand. The goal is to get familiar with the problem. Most of the time this session makes two kinds of developers emerge: UML-makers and test-drivers. The first kind typically spends a lot of time on designing a Death Star that is able to simulate Game of Life as well, and end up having coded nothing more than a simple data structure or a factory. Test-drivers usually write a few, sometimes a little bit complicated tests first, then write a few methods in the production classes, then debug for some time, then end up with a completely blown-up code base when the test for the next requirement to be implemented breaks everything that seemed to work until then. Most people don’t get to implement a single rule of the game, which is quite interesting, since the game does not seem to be that complicated at first glance.

Baby steps and TDD

The promise that TDD advocators often tell is that if it’s done right then debugging times can dramatically shrink. Since you are always a couple of minutes away from a green bar, it’s not a big deal to revert all your changes to that point in case you got into trouble. However, if your steps become too large, you may find yourself tens or even hundreds of code lines away from the last working state, so when you encounter an unexpected failure, you either throw away serious amounts of work, or you fire up your debugger or begin to add print statements to find out what’s happening and how it should be fixed. This is sad because you’re paid to write working code, not to throw some hack together then debug it to a point when it seems to be working, at least on your machine. That’s why baby steps are often emphasized at Code Retreat sessions: learning to take small incremental steps both in test, in production code and in the overall design can help getting that promise about less debugging and ability to throw away troublesome code and to explore other directions to move forward become true.

What is often hard to get the idea of is faking implementation. Why would anyone write return 0 just to pass a test, knowing that it will be overwritten in less than a minute? Aside from practicing the thought process, it’s similar to stubbing database layers in test harnesses: there’s something that’s out of your test’s scope. Real database setup and communication can make tests run slow, and anyways, when you’re testing your business logic, you don’t really want to test your 3rd party ORM tools and database adapters at the same time, otherwise your test failures won’t be able to tell which layer of your application may be broken. Fake implementations are somewhat similar to that idea: you use stub implementations (temporarily) in parts of the code you are developing that are out of the scope of tests written so far or don’t really belong to the abstraction you are working on.

For example, in case of Game of Life, it’s a good idea to write a test for the first rule first: this rule states that cells with less than two living neighbors must be dead in the next generation. The test will place a lonely cell and one with only one neighbor on the map, then produce the second generation and assert that all three cells are dead in that generation. Returning an empty array in the production code can make all those assertions pass. Since such a simple code can pass this test, it must be either wrong, or it is not really testing death of cells, at least at this point. The latter idea seems to make more sense, and if you think about it, the short-term value of this first test is a demonstration of the interface of the class under development. Looking at this first test, you may decide to make the interface more simple, rename some methods or experiment with other metaphors, etc. From this point of view, any more production code than what is enough to demonstrate a return value of a method may be considered out of scope.

The second rule states that any living cell that has two or three neighbors must live on to the next generation. The test for it may set up a configuration in which all the cells have two or three neighbors and assert that all of them survive. You see it fail, then write a loop that puts cells from the previous generation to the next if they have 2 or 3 neighbors, but how do you know the number of neighbors? Now you could write another loop to iterate over all the neighbors of a cell and increment a counter inside an if statement that verifies if a neighbor is alive, but that together means at least two loops and two if statements for just two tests. Game of Life is simple enough to write all that code at once in seconds without errors, but the job is not to write a working Game of Life but to explore techniques and mindset often associated with TDD, so let’s find an even smaller step instead! One might write a method that counts neighbors and make it return a value derived from the total number of cells on the map for example. This can make the second test pass by adding a loop and a conditional implementing the logic needed to make cells survive depending on the number of their neighbors (but not on the neighbors themselves nor on their position nor on anything else), forming one layer of abstraction, and a fake implementation for a different abstraction layer (ie. the neighbors). If you like, that stub for neighbor counting can be viewed as a degenerate neighbor counter that consideres every cell on the map a neighbor to each other. Test for the third rule will encourage you to replace that fake neighbor counter to a real one anyways. Until then, you have the fewest code possible, making it easier to refactor if you feel that things are going to a wrong or unnecessarily complicated direction. The less code you have in your way, the easier is is to spot and restructure the parts you don’t like.

2 parameters, 3 lines

These constraints are about simplistic, concise code. It’s nearly impossible to write code meeting these constraints at the first time, so you are encouraged to get there by refactoring. Doing so you might find that extracting a few small functions and making complicated ones to be compositions of those can enable nice functional programming tools, and also get a glimpse on what and when to extract, since following such rigid constraints blindly can lead to a code that is more obfuscated than clean. Applying the same restrictions on the test code can remove all the duplication in it as well, making the test less sensitive to even big changes in the structure and API of the production code, which is a good idea anyways. If your tests are in the way of refactoring, you loose all the benefits those tests were made to enable in the first place.

Agile sessions

Agile software development promotes the idea of responding to changes quickly and safely. Thoroughly unit tested code makes this possible by letting you refactor without fear before implementing a new requirement so you can add it to the system conforming to the Open/Closed Principle. New features are implemented by adding new code, not by patching and duct taping existing modules, right? Of course such a flexible architecture that enables that is impractical, if not impossible to create, but after an educated refactoring based on the knowledge of new requirements, you can nicely conform to that principle after all. To demonstrate the concept of such evolutionary design and how test-driven code can help during that process, we’ve come up with the idea of CR sessions involving unexpected requirement changes. Such a session is typically a longer one, we usually join the two last sessions for this experiment. During that we wait for participants to get close to a finished implementation of the Game, but before that could happen, we introduce a new requirement, for example, the age of cells, configurable rules, weight of cells inherited birth-time from the three neighbors, sometimes even hexagonal cells. Implementing any of these can be tricky in an architecture that was not designed with these features in mind and is obsessed with language primitives all over the place, but after isolating some behaviors, extracting relevant responsibilities or introducing new layers of abstractions, they are almost trivial to implement.

Legacy code

Unnecessary coupling and the lack of tests can make any code extremely hard to maintain. To learn the basics of getting bad code under test and then refactor it to be able to add features is quite hard to do during everyday work, but at a Code Retreat, people can safely experiment with it. That’s why I created this horrible implementation of the Game for our internal Code Retreat. It has a loop that can easily become an infinite one, it prints on the console, there are copy&paste snippets here and there, and to make things worse, it often employs bad naming and some overcomplicated helper methods. And we wanted new features in this mess that affected both the code responsible for applying the rules of the Game and the printing logic as well!

Most pairs find out quickly how to get rid of the infinite while loop in evolve() and how to isolate printing and the string representation of the Game’s state from the main logic, and after a few trivial changes, they could easily get the code under test. Some pairs even started by safeguarding those initial dependency-breaking refactorings with end-to-end tests so they were covered from the very beginning. In the end, many of the pairs managed to get a code base they could work with and test-drive the new features in, but for example, those who attempted to rewrite the code from scratch, had a hard time doing it and still failed, and to make things worse, they had painful debugging sessions as well. Imagine how rewriting code you don’t understand can fail if rewriting one that implements well known requirements fails so badly!

Conclusion

I can totally accept that some people still don’t like the idea of TDD and the quite unnatural ways of thinking associated with it and with evolutionary design. I just don’t want to end up integrating or maintaining their code.

Thanks

I would like to say thank you to all the people at BalaBit who have a positive attitude towards learning and practicing the craft this way, and of course to all the craftsmen at Budapest who sacrificed a Saturday for practicing their profession! Meet you on the second Global Day of Code Retreat, on December 8th! And of course, greetings to fellow developers in London, who were also honing the craft on September 29th.