Homepage ->  Developer Testing  -> Good development depends on good testing

April 02, 2007 - Good development depends on good testing

Sometimes an aphorism like “good development depends on good communication” doesn’t really sink in until it hits you upside the head. I experienced the reality behind this particular maxim recently when I expanded the number of developers on an open source project from one developer, myself, to two.

For the past year I've been the sole contributor to an open source project. It's a client library for the network protocol, "InSim", used by a racing simulator called "Live For Speed". The protocol sends out different types of information for simulated races, which can be used in a number of ways. I wanted to use the telemetric data to drive the type of gauges that are found in real cars. Many people use the race results data to keep statistical databases, usually for simulated racing leagues.

My project, JInSim, is a Java library that interprets the network traffic coming from Live For Speed and turns it into easy to use Java objects. It's a niche project, so my expectation was that there would be a small number of downloads that would translate into an even smaller number of heavy users. One of the heaviest users is using it to keep statistics for his Austrian league to generate web pages that show things like the current standings in the league, or the lap-by-lap results of their last race. He recently sent me a set of patches that added features in the latest version of the simulator. Over time he had sent me a few patches, so with this set of patches I decided to make him a co-developer on JInSim. This is where I began to learn some things about communication.

In development, good communication takes a number of forms. At the highest level, there is direct communication among members of a development team; team meetings, email, instant messages. Depending on the team, there are also different forms of indirect communication; specs, stories, use cases, wikis. At the lowest level there is implied communication; source code and tests. Reality lies at this lowest level. The other levels are just abstract hopes, but the code is the truth. That's why I should have checked my tests into the project. I was only telling my new co-developer a half-truth.

JInSim is one of the personal projects I use for testing at Agitar. I have a suite of 900 tests from JUnit Factory that characterize and document the behavior of the code. Making these tests available to anyone who has any interest in the code would have been a good thing to do. Unfortunately, it's something I didn't do. By not including this communication in the development process, I had made the project less good.

My co-developer checked in changes almost as soon as he had the ability. When I updated my source code later that day, I found a significant number of changes and a large number of compile errors in my tests. The tests I hadn't checked in. The silver lining in this dark cloud is that these "failing" tests gave me a good idea about what had been changed.

The changes he made were really just API changes, so they weren’t difficult to fix, but there were a lot of places in the code that needed changing. It took some time to make the tests compile, but it didn't take a lot of thinking. If the changes had been more intricate, there is a good chance that the tests would have been useless. It would have been better if the tests would have been available to him, to use his knowledge of the changes to fix the tests. This might have lead to more communications about my original intent with the code, and better communication all around. So, by not checking in the tests I left him with a misunderstanding about how I meant the code to work, and I left myself with a bunch of broken tests.

If you want your project to succeed, you need to make sure that you’re communicating at all levels. Tests are part of that communication. They are a great part of that communication, because they don’t only communicate information about the code, but they also foster other forms of communication when they fail.

They are also a key part of another aphorism that’s hit us all upside the head:

“Good development depends on good testing”.


Posted by Rob Heiser at April 2, 2007 03:16 PM


Trackback Pings

TrackBack URL for this entry:


Comments

So have you committed your tests yet?

If not, why?

Posted by: Jeffrey Fredrick [TypeKey Profile Page] on April 5, 2007 12:11 PM

Post a comment




Remember Me?