Thursday, February 17, 2011

Unit Testing ROI

In my experience everybody knows for sure unit testing is a good thing. But then again it puzzles me why nobody is actually doing it... I think one of the biggest misconceptions is that everyone thinks that unit testing pays back over time or in the long run. This is not true! There is a more immediate payback on your investment that pays off from the very first line of code! The returns on Unit Testing grow exponentially over time...

All projects go relatively smooth the first few months until they reach a certain point where the skeletons start falling out of the closet... Regression bugs start to appear at an alarming rate, it takes longer to detect errors, more time is spent in the debugger than actually writing code, it gets harder to add new functionality,etc,...

Unit testing will:

  • Reduce the time spent in the debugger
  • Reduce time to test your code as a developer
  • Enables you to refactor

Reduce the time spent in the debugger

if you consistently write (good) unit tests you will be focusing on smaller portions of your code and thus preventing you to have to step through your whole application. When running all your unit tests you will automatically see when you break existing functionality, like this you will hunt down the likely cause a lot quicker (probably it was that last bit of code you changed).

Reduce time to test your code as a developer

When you unit test your code those little forms with one "test" button will be of the past. An other thing which will save you tremendous amounts of time is that it is no longer needed to step through a series of screens before you actually get to the functionality you want to test.

Enabling refactoring

If you have unit tests you can refactor those methods and classes that grow an keep growing... Everybody knows these little black holes in any application that are a pain to modify and every team member is reluctant to make modifications out of fear to break something else.

NDepend Enables you to quickly identify where problems will start arising. Find below some useful queries.

Types that are to big and need to be slimmed down

WARN IF Count > 0 IN SELECT TYPES WHERE
   NbLinesOfCode > 500 OR
   NbILInstructions > 3000
   ORDER BY NbLinesOfCode DESC

for more information: http://www.ndepend.com/Metrics.aspx#NbLinesOfCode

Methods that are to big or to complex

WARN IF Count > 0 IN SELECT METHODS WHERE
  ILCyclomaticComplexity > 40 AND
  ILNestingDepth > 4

OR NbLinesOfCode > 50 //Can even be smaller
  ORDER BY ILCyclomaticComplexity DESC

for more information: http://www.ndepend.com/Metrics.aspx#ILCC

Thursday, February 03, 2011

C# 4.0 Code Contracts:

I was trying out the code contracts in C# 4.0 and came across something quite surprising every time I ran my unit tests I got an annoying message box popping up “Assert Failure”, Description must use the rewriter when using Contract.Requires<TException>.

After some googling around I found that in Project Properties you need to find the code contracts tab and set “Perform Runtime Contract Checking” to full.

I opened my project properties I realized I did not have the Code Contracts tab… So in order to enable this tab you will need to install Code Contracts from DevLabs (here: http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx).

Rebuild and he complained about the Assembly Mode Setting not being appropiate. After Changing it I could run my tests without having to click every time a testmethod came in the method that had the contract.

Problem solved!

Interface Contracts

One problem I came across is that when trying Interface contracts I had an assembly that ended in Contracts and apparently it does not work (Code Contracts will compile its contracts in a assembly named <assembly name>.Contracts.dll. I renamed the assembly to IContracts and everything worked as expected