Usable code and TDD

There’s a strong link between TDD and the usability of a code base, they go hand in hand.

By usability I mean how easy it is to steadily add features to it (you can read more on the concept by A. Bolboaca). The relationship between TDD and usability is that whenever it is difficult to use TDD in some piece of software there’s a reason for it - its usability level is very low. It follows that if developers work with a low usability tool (the code base), then development is not fast.

Let me explain why inability to use TDD on some codebases also makes it not usable for any other type of development. To understand that we need to look at what we need for writing a test before the code. Besides training in TDD, we need to know:

• How to put the system (or class) in a relevant state => SETUP
• Where the new behaviour will reside  => ACT (which class/function to call)
• Which state or side effects to expect as a result of an action => ASSERT

Now this is difficult if interactions are complex because it is difficult to learn and memorise what to expect and assert for. Basically we’ve scored badly at two of the five usability criteria. Say we’re in a situation where we know not so much of the necessary outputs, we don’t know what to assert for, then our major concern is not to use TDD (to raise the chance that we’re implementing what we think we are) but to find out which outputs we weren’t aware of in the first place. This is often done by switching to the trial-and-error approach: change something, run the application, change something, run ….  But remember, the reason we switched from TDD to trial-and-error  is because it is difficult to cognitively master the application. 

Is the trial-and-error approach slow? Not always, but it goes with quite some manual testing and chances are we’ll still leave a few bugs in there to be discovered and fixed later and that is far from free. In addition we’ll avoid refactoring to not break more than necessary thus leaving more than necessary complexity in there and to further slow down the next feature.

I claim that IF it is difficult to do TDD on an application THEN it is in a state where even good developers have a hard time mastering the complex interactions and everyone will work slowly all while making the problem worse! The good news is that I’ve seen this problem being pretty much solved in various applications. It also means that if you do TDD or at least write good tests you’re likely to create an application with a high degree of usability, simply because you’ll have to remove accidental complexity.

Stay tuned an example will follow