Unit testing and tracer code

There are moments during development where you realize some things are not that easy, here is a result I achieved experimenting with rectilinear connection editing earlier today 🙂

Rectilinear bug

Here is what I really wanted to do:

Expected result

It is clear that it is a good idea to create a test suite for something as complex as rectilinear editing. When it comes to an interactive application, you often reach the limits of test-driven development. In particular, how do you express the tests about how an interaction should work, if you can’t imagine it ?

Therefore, if I want to design an interaction, I usually do “explore-first”, which means to write tracer code, like in the above example. It helps me to explore how to write the code and/or the tests when I have absolutely no idea. It is not a prototype in the strictest sense, since the code has production quality (or what I consider to be production quality) from the beginning. I just can’t write prototypical code, which for me is a good thing, because once I have fleshed out the functionality, I am practically finished.

Sometimes you have to scratch and bite to impement a feature. This is particularly true for client applications, where you can lose yourself in the details (now I am happy not to have used AJAX, I probably would have lost myself in Javascript 🙂 ). I am now the second day into this feature and this one turns out to be even more complex than I thought. Granted, I could just have ducked away, because rectilinear connections can be created using the generic connection type. That’s exactly what I don’t want. Rectilinear connection editing is a useful feature, because it let’s the user create this particular connection style with fewer interactions than the generic way would do.

This is also an example that even though the general advice is to tackle the hardest problems first, that this is not always possible. In this case, I needed to have the basic abstractions available and get the understanding about them in order to design the feature in this context. Often the understanding of the system in development has to grow before more difficult tasks can be executed.

Even though I could probably hack it in until tomorrow, I would not be happy without the tests in place. I take a rather liberal approach to unit testing, but in this case, I insist to have a test suite. So I will need to push my release date to next Monday. I am sure that these additional four days will result in higher quality.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: