I have to confess that I don’t religiously take on TDD / Unit Testing all the time.  Most of the time when prototyping I use regular C# console app or better yet, fire up jsfiddle.net and hack away at the things that I want to proof using JavaScript.   Most of the time this workflow do what I need it to do.  I can get the result that I want and pretty confident that the code works before I migrate it back to real production code in C#.   Perhaps sometimes after I’ll code up some unit tests to get some coverage.

Digressing a bit… I love jsfiddle and things like dotnetfiddle since they allow me to prototype stuffs without having to go through the code, wait for compile and run to see what’s coming out at the other end, but that’s a different story. *Digression mode OFF*

I found that most of the time when I really feel that I need to fall back to TDD / up front unit testing is when dealing with compilcated logic like rules that depends on multiple if statements… like…

If it’s Tuesday and it is raining and you’re wearing red socks then do this

If it’s Tuesday and it is raining and you’re wearing blue socks then do that

If it’s Tuesday but it’s a leap year and it’s between January to March, and you are wearing either black, blue or red sock but also wearing sweater, then do something else.

You get my point…. some codes are just harder to hold in your head and get right.   Complex boolean logic is one such thing.  This type of code is a perfect candidate for starting with TDD.

I had to work on some brownfield code for a client which has this kind of logic to determine if a node in a treeview or the screen entry is enabled… what a headache :).   Unit Testing came to the rescue.  The result is… I  am more confident now that the boolean logic that I put into the code works as expected since I coded enough test to cover every conceivable scenario of the business rule / requirement.

Agree?  Disagree?

What do you do?