6/15/2009 9:24:02 PM #

@ CSharpRox:

(Sorry about your comment not appearing immediately. I get a lot of comment spam, so I leave moderation on for comments.)

I use Debug.Assert just about everywhere in my code. It's not really part of TDD, in my opinion. It's more about making sure that the code is used correctly, and trying to identify places where the code might fail. I pretty much never use Debug.Assert with my test code, instead using the Assert functions that come with the testing framework like NUnit, for example.

Take for example, when creating a method in .NET, the .NET library defines exception types such as ArgumentException or ArgumentNullException that you're supposed to raise if you receive a bad argument. The reason why I don't like this is that it seems like these exceptions are more for development time than production time. I'd rather receive a Debug.Assert error that indicates that a method is being called incorrectly by my code because there's more that I can do with it when I get the assertion error. I almost never implement a try...catch block for ArgumentException, so if the exception is raised it's going to cause my application to crash because of an unhandled exception. The only way that I'll know about the unhandled exception is if I log it, or if I capture a mini-dump to figure out that I'm calling a method incorrectly.

The difference is that with Debug.Assert, I get an immediate response that tells me exactly where the code failed and I can go in and fix it. Of course, this isn't going to help you in the release build because Debug.xxx methods will be conditionally ignored in a release build, so in that case you might want to follow up your Debug.Assert code with throwing the real exceptions later on in your code.

When it comes to debugging code, few developers really "get it." Most think of debugging as stepping through their code trying to figure out why the program is failing. But debugging is more defensive programming by giving yourself as many options as possible to figure out why the software might be failing, and using Debug.Asserts in lots of places means that you're ultimately going to have better software.

I also get a lot of push back on my teams on tracing and DebugView. It goes back to what I was saying about the difference between logging and tracing. Many people don't understand the difference between the two. Logging's more for operational monitoring, but tracing is for debugging.

I get a lot of questions from senior-level developers and architects asking why I want to put in tracing. They point out that it's not going to do much good when it's on a user's machine in production because nobody's going to ask the user to turn on tracing on their machine. I don't really buy that argument. Why is it so bad to ask them to do that if every other support option has been exhausted. It's another tool that may or may not be used. But most importantly, tracing provides value to me as a developer in supporting the software in production. If the user can't turn it on, I can turn it on when I'm running the software in my machine trying to reproduce their steps.

The best advice that I can give you is to keep doing what you're doing with DebugView and Debug.Asserts. Eventually, their value is going to prove themselves, and the developers that are questioning you will learn it when the software does fail in a production environment.

Michael

michael