nCrunch review – TDD on steroids

No comments

Saturday, December 29, 2012

Any project that uses unit tests gets to the stage where running all of the tests takes a lot of time. Even if you manage to keep your test suite in a manageable size From time to time a developer would “forget” to run all the tests before commit and break the build.

One solution for these problems is to have an automatic test runner/continuous testing tool that runs the tests automatically.

The idea of continuous testing has it’s roots in the Java world. JUnitMax which was create by Kent Beck, runs all of the tests on each save. The order of the tests is determined by risk – the first tests run were the ones that failed on the previous run. Although this solution does not solve long run times it does make sure that your code is constantly being verified.

In the .NET space there are several such tools one of which shine above the rest -  nCrunch.

Getting started

nCrunch is code coverage, test runner and performance analyzer all in one. Using it is simple – all you need to do is to choose to enable it and after filling a few options you’re ready to go.

You can choose how many CPU cores to dedicate to running of tests and whether or not you wish to run your tests in parallel. Another option is to run the test manually – in case you “only” wish to use nCrunch as a test runner.

Running nCrunch

After this short configuration nCrunch would automatically discover all of the unit test in your solution and try to run them. So far I’ve used it with NUnit, and XUnit and it worked perfectly. On each save the code is compiled, and tests are run . nCrunch can be configured to run only the tests affected by the last code change. I’ve used this option thus avoiding a long test run with each change I make.

Another plus is the continuous code coverage results, each line of code written is immediately marked as covered/not covered by unit tests and if that unit test(s) fail – it is also marked in red.

When a test fails nCrunch provide full exception information and an arsenal of debugging options to choose from – from simple “run in debug” to “Break into the first failing covering test at this line”.

Supercharge your unit tests

nCrunch is one of these tools I’ve been looking for without actually realizing it. Using it makes TDD (Test Drive Development) easy to follow. If you want an excellent example – take a look at this video (YouTube):

Around 1:10 it really gets interesting when the code is written and the tests are executed side by side


nCrunch is not the only continuous testing tool out there but it’s certainly the most mature one – with easy configuration and many useful features it’s the unit testing productivity tool that I was look for.

Serialization and events in C#

1 comment

Wednesday, December 19, 2012

Today I had an interesting problem:
I was trying to serialize and object using BinaryFormatter but it kept on failing because some class was not Serializable. I’ve double and triple checked my class and all of it’s inner properties and verified that indeed they were marked correctly.

The Problem

Looking closer at the exception I’ve noticed something – the problematic class that was causing me grief was not part of the class. In fact the problematic class was signed to an event of the class I was trying to serialize. SO I had the following code:
var myObj = new SerializableClass();

var notSerializble = new NotSerializableClass(myObj);

IFormatter formatter = new BinaryFormatter();

using (Stream stream = new MemoryStream())
    formatter.Serialize(stream, myObj);
And the the class – NotSerializableClass was something like this:
public class NotSerializableClass
    private SerializableClass myObj;

    public NotSerializableClass(SerializableClass myObj)
        myObj.someEvent += HandleSomeEvent;


And so the fact that it was attached to the event from my perfectly serializable class caused the problem – the BinaryFormatter was trying to serialize it as well!

The Solution

Once I understood the problem the solution was simple – I’ve marked the event as field:NonSerialized and the problem was solved:

public class SerializableClass
    public event EventHandler someEvent;

Simple – as long as you know what to look for.

Agile might save your job

No comments

Tuesday, December 04, 2012

Imagine this: you have two employees, both are hardworking and bright.

You have complete knowledge of what the first employee does, which task he’s working on and its deadline while you have absolutely no idea what the other employee does. While the first employee shows progress every few weeks with new release, the other commits to quarterly plan. The first employee give you daily progress report and notify in advance when he’s going to miss a deadline or a feature.

Now imagine that you must fire one of your employees – which would you choose?




Truth be told most managers prefer employees that shows progress and keeps them well informed.

So how can one protect his job – simply by making sure that his manager and manager’s manger are aware of the state of the tasks under his responsibility and if a deadline is going to be missed – be notify about it as soon as possible – because no manager loves surprises as far as his project is concerned.

The thing is that all of this and more is part of several agile methodologies. It does not matter if you practice SCRUM, Kanban or Lean notifying your manager and tracking progress is an integral part of the process used.

It also helps that following agile methodologies would guarantee that progress is always seen – one iteration after the other.


And the moral of this story (as you might have guessed) is that the Agile team was not fired and they get to do at least one more iteration.


Just a thought…

Related Posts Plugin for WordPress, Blogger...