Sunday, July 25, 2010

I'm TestDriven.Net

Thanks to the chaps over at I got the opportunity to test their product.

So, one of the real problems with Visual Studio when it comes to unit testing your code is it is really slow and unproductive.

If I write a test method in C#, I often want to quickly run it and run it often as this is the whole point of TDD isn't it. If you use MSTest you'll probably find this is the slowest testing tool available but its great integration with TFS often makes it a desirable choice.

To quickly test our method we normally right click the method in code, and select "Run Tests". This will (if a MSTest) switch to the Test Results window and show you the result of the test, great.'ll find this quite slow. Then what if you want to debug a test. First you have to run the individual test as said above, then check the check box and hit Debug Test.

This is fine but all very time consuming, why can't I just say Debug this test without having to run it first, check the check box, then hit Debug test.

This is where TestDriven.Net comes into play. Now after installing the tool, I have a new menu item when right clicking my test "CanResolveTransientComponent":

So here I can hit "Run Test(s)" and it will execute the test in a fraction of the time that Visual Studio will do it. When doing this, TestDriven.Net will switch to the output window and show the test output:

So 0.36 seconds is pretty fast. When running via Visual Studio it is much longer, perhaps around 2 seconds for the same test.

The reason for this is when you execute via TestDriven.Net, it omits MSTest code coverage. This greatly speeds up the testing process. If and when you're interested in code coverage you can ask TestDriven.Net to give it to you.

There is a submenu when you right click your test method:

I like this submenu alot. It gives great flexibility in how you run your tests. If you want to simply debug your test without have to go through the lengthy steps mentioned earlier, simply select "Debugger". Sweet.

As mentioned earlier regarding code coverage. When quickly executing a test the MSTest code coverage is omitted in order to speed up the test greatly. But if you want MSTest code coverage then you can select "Coverage" from this handy submenu. This will give you pretty much the same results as if you ran the test via Visual Studio itself.

As you can probably see, if you use another test tool other than MSTest, there is integration for NCover. In fact NCover works for MSTest too. Selecting NCover from the submenu fires up the NCover Explorer tool that gives you a code coverage for the test(s) you have selected to run:

This is a great feature, I do like this.

Another really cool feature that I'd like to mention is support for performance testing. Selecting "Performance" from the TestDriven.Net submenu gives you a nice breakdown of performance data for your test:

There are many more features to checkout with TestDriven.Net and I recommend you check them out.


Matt Davis (bronumski) said...

Do you use code coverage on TeamCity? If you use MSBuild you can get it to fail the build if you coverage drops too low :)

By the way where is you Test Driven logo?

Simon Hart said...

TeamCity?? why would I use TeamCity when I have TFS! :)

I think this whole code coverage thing is blown out of proportion. I'm more interested in Style rules. So long as developers honour the SOLID principle or at least the single responsibility principle I don't think 100% code coverage matters too much.

I've seem shops where they mock everything because their code is so tightly coupled and objects are doing way too much and they have code coverage contraints on the build server. As soon as you change anything a whole bunch of tests fail because they are so britle.

This is where something like StyleCop could be enhanced or perhaps FxCop to be more useful and validating code design.