Test Driven Development - Reaching your destination with NCrunch

Every time I have to drive my car somewhere far I use a GPS device to navigate to my destination. I can see what’s going on with my route and adjust to new conditions instantly without too much attention. In the old days I would have to stop and check the map. Probably very often. Car navigation gives me many advantages, for example:

  • I see if I’m going in the right direction
  • I can verify my route
  • I see if I am making any progress

And this all happens instantly, without having to stop, no time lost, no unnecessary kilometers made.

I like to imagine the good old paper maps verification as a kind of tests. Tests to our progress on the road. They take time and extra effort but are crucial to reaching the destination. I also like to think about the car navigation as an continuous testing framework to our journey. Am I crazy?

I believe I haven’t lost my sanity yet. I’m only a geek. Geek that’s just found his new favourite toy. It’s called The NCrunch.

It’s sole purpose is continuous testing with code coverage. These two kinds of tools are already existing, so why bother? I believe it’s the way that NCrunch is architected. It works so nice that it instantly makes you wanna sit down and write some awesome code. It’s giving you an immediate feedback about the results of tests and the coverage of code. You don’t have to fire tests. You don’t have run code coverage. You don’t have to navigate to find out what lines are failing. No IDE hangs. No blocking. The programming never stops.

It basically works like this - a normal class with test cases will show up as:

That’s it. Notice the little green dots. These guys signal that the line they’re at is correctly passing tests. If a part of code doesn’t have a test case for it then it will look like this:

Now the programmer immediately sees that we don’t know what to do with this result. We don’t have a test for it. If we don’t have a test then how are we going to be sure that the code is executing correctly? How do we know it’s working according to the spec? One thing has to be done. It’s clear that a developer should add a test to this case.

But what if he by mistake breaks a test? How does he know that? Well usually he would press “run all tests”, wait few years and then BAM! a test has failed. Well NCrunch does it for you, noticing what you change. You will instantly see:

Pretty darn useful, isn’t it? You should use NCrunch or at least something that does these tricks.

Its biggest advantage is that it works seamlessly in the background and runs tests immediately you make any changes.

There is more to it. I recommend installing and seeing for yourself.