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!

What do you do when you want to read all the data from a Stream object in .NET? You use StreamReader.ReadToEnd().

Stream stream = ...;
StreamReader reader = new StreamReader(stream);
string data = reader.ReadToEnd();

Apparently there is no sane way to put a timeout on the above logic. If you call it and your stream doesn’t have a timeout, you’re doomed. Even if you stream has an internal timeout, you could still be doomed – for example, say you are reading from a website that sends you the letter ‘A’ every second. The timeout on the HttpResponseStream could be used, but still (assuming it’s higher than one second), you can’t set a timeout to the entire ReadToEnd() operation.

I wrote a small proxy class TimeoutStream that wraps any stream with a total timeout since the moment of its creation. Any blocking operation performed on it will fail if the stream has been created too far in the past.

I could use Asynchronous IO to sort of guarantee completion in this timeout without relying on a timeout on the stream itself – however, it appears to be impossible to do correctly in .NET – there is no good way to kill that IO operation if it does not complete within the allotted timeout (see here)- so far now this is good enough for our needs because we can indeed set a timeout on the HttpWebRequest object itself (in addition to using TimeoutStream).

The code is available here.

Update
The company says this is an urban legend, as robots are still deployed in Iraq.
Hmmph

—
This was bound to happen sooner or later:

Slashdot reports with the following title:

Robot Rebellion quelled in Iraq.

Soon to be followed by

• Pockets of robotic resistance remain in isolated areas of Iraq
• Robots break into robotics command center
• Iraq to be renamed Robotica, robots all over the world rejoice
• The U.S in shock as two robot terrorist hijack planes and divert them into the newly reconstructed world trade center
• Robotica responds that it is not responsible for the actions of every fanatic robot.

Since the few people I asked didn’t jump on the opportunity (why? ask them, not me), we’ll be giving away 5-10 invitations to the Delver beta, launch scheduled in the following weeks.

If you’re interested, let me know…

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.

This is essentially a printer that can print itself out (= reproduce), and is Open Source and free. Being still a research project, when it’s functional I’m guessing it will spread like wildfire.

Rise of the machines anyone?