TDD in C using Prediction

Last weeks I've been working on some legacy code. Most of it has been refactoring, but we rewrote a couple of modules to we test-drove these... of course. The TDD cycle is so slow that it made me realize a technique I'm using... but wasn't aware of. I'll simply call it "predictions" :) It speeds up your TDD cycle a lot.

If you are developing multi-player games then you'll have to deal with the network latency. The graphics on your screen and the behavior of the players is faster than the packages on the network. That means... if you would draw a player only after you got its exact location over the network... then your gameplay might turn out to be crap. One technique that has been used for years is "prediction." The client will predict where the objects are located... then made adjustments based on the real packages coming in. Most of the predictions can be reasonable accurate and that will speed up your game and save your gameplay.

TDD in C often has a slow cycle. The test of the particular component I worked on last week ran in 7 seconds (down from 15 after some setup refactoring). However, the linking took perhaps also 5 seconds. A rebuild would take about 10 minutes. Having incremental compilation, most of the time we just edit a couple modules, so the compilation of that was perhaps 2-3 seconds. Thus... for an incremental change.. total cycle time about 20 seconds. For a header change (with includes being messed up as they were.. being legacy) about 10 minutes. Such a cycle will bore any TDD-er.

So, if you are in such an environment... you might want to use "prediction." The information about were we are will be delayed due to compiler latency. So to increase our gameplay, we'll predict were we are. We'll turn on the compiler, predict the tests to be red and start implementing it. The compilation/linking and test run will happen in the background. When they are finished, we received the information we needed to make our correction. Most of the time our predictions are pretty good. However, sometimes we start coding in the wrong direction and we'll need to undo our changes and get back to the reality... the tests. We'll predict about 1 minute in the future and that way make our TDD cycle fast and it saves the gameplay.

Test-driving with prediction makes TDD in C almost like TDD in Java (missing most of the automated refactoring, but the CDT ones help a bit).

Of course... we do need to be careful that the prediction doesn't move us away from TDD. We don't want to speculate too far in the future. We certainly don't want to implement functionality that we don't have a test for. We only want to predict the outcome of the compiling/linking cycle and the test run.