A Quantum Immortal

Funny – just today I read that the great Donald Knuth, in a recent interview, dissed unit-testing:

“As to your real question, the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

(In this interview he also talked against multi-core paradigm (which may be the only way to keep up with Moor’s law due to our CPUs getting hotter and hotter), but that’s a different story).

Why is this funny? Because just today at work I installed JetBrains’ TeamCity – a very fine unit test and automated build suite. Sadly I didn’t have time to finish configuring it today, but I already see the great benefit this will bring to all our development team. It goes beyond a simple automated build system (which is important enough, making sure no member of the team messes something up by accident, opening up new venues for brave code refactoring).

TeamCity aims to take all resource-intensive activities off the developer’s computer. Just some of its features are (I didn’t have the chance to test them, but I believe JetBrains – these are the guys that make Resharper after all):

• Code Analysis (finding code and style errors)
• Code Duplication – automatically find the copy-pastes I hate so much, with configurable granularity (java only, coming soon for .NET)
• Pre-commit Build – Suppose it is now 8PM, you’re about to leave for home, and unfortunately you have a rather large piece of uncommited (checked out) code. What do you do? You do not commit the code. Why? Because there’s a good chance it will screw up the build and you don’t want to leave the common integration area messy. To the rescue comes the Pre-commit Build feature – you can commit the code, have TeamCity catch your commit before it actually happens, test it automatically on a build agent (dedicated build machine), and then only if the code compiles and all tests pass it will check in the code for you. You do not have to wait for tests anymore! This frees up developer’s time for actual development, while preserving the high benefits of unit-testing (that Knuth doesn’t see, for some reason).
• I’m sure it has load of other features I haven’t dug up yet – among them the ability to run tests without any commit process “just for fun”, it’s ability to smoothly handle multiple Agents (each running a configurable number of builds concurrently), supporting multiple source controls, IDEs and development languages, ICQ/RSS/Jabber support, and last but not least a button “Run this test on the fastest available test machine”.

So far the systems I’ve used for unit-testing were:

1. Manually running unit-tests a couple of times, then forgetting about them 🙂
2. A patched-up system that automatically runs tests for you on checkin, with a build status indicator that Gal Golan in my development crew in the army wrote himself
3. CruiseControl.NET – an open source project that does something similar to the above, only slightly more configurable

As you can see by the length of this post, I’m excited to try on a professional solution to this problem for once 🙂 And for those of you that got this far, let me add that it’s free or charge – for up to 3 Build Agents and 20 developers. Huzza!

This concept has been revisited in many Extreme Programming articles so I will not blab about it much, but I do want to raise the point – mainly because it is still not a universal practice.

A key feature of a good programmer is courage. A “cowardly” programmer will see a non-critical problem or an ugly hack begging to be refactored and will shy away from it on the grounds that it his not his concern at the moment and it will probably break the world and introduce bugs to the system. A “courageous” programmer (backup up with properly written unit tests, of course), will refactor the ugliness away, thus incrementally beautifying his code.

This overall process, reiterated over the product lifetime, will either produce a convulated codebase with loops, noodles and baggage (for the “cowardly” programmer), or will result in a clean, easy to use and modular code for the “courageous” one.

While refactoring is a time consuming activity at times, it is well worth the momentarily increased coding time, because the overall coding (including maintenance!) time for him and his entire team will be decreased significantly.

The existence of well written unit tests is crucial to this, for without it you really can’t know if you introduce bugs or not. With unit tests, you get a significant “courage boost”, allowing you to do major changes that affect many files – for the better – because you are reasonably certain that any change will indeed be detected.

On the other feature of a good programmer – laziness – in another time.