Software QA FYI - SQAFYI

Debugging in .NET

By: automatedQA

Debugging is one of the most painful parts of the entire software development process. We don't want to describe how hard it can be to find one little bug - you probably all know this already... possibly, too well. The amount of bugs in programs increases with product complexity and often when bugs aren't fixed in time, they can interact and produce extra complexities in a project that is complex itself. So, we are trying to constantly monitor and eliminate bugs.

The best way to monitor bugs is to perform unit testing but, when it says that a test has failed, it doesn't say why and our task is to trace the execution process to see what's wrong.

In this article we just want to describe how this process can be simplified when using the .NET Framework debugging and tracing means. We'll briefly tell you how to use them efficiently, plus we'll you give some examples of this.

Tracing The first debugging strategy to be discussed in this article is tracing. Tracing can be a very powerful technique in skillful hands, because it allows you to see the whole picture of the application run time behavior and analyze it more efficiently, although it cannot provide information by request.

Tracing support in .NET is covered (as most of the other debug components) in the System.Diagnostics namespace, exactly in the Trace class.

Trace is a static class (which means that all its members are static and you don't need to instantiate it to get the key to its functionality). It allows you to do the following:

Raise an assertion (conditional or not) Output trace messages with condition support Format the trace output Let's start discovering its possibilities with a brief member's overview:

public static void Assert(bool) public static void Assert(bool, string) public static void Assert(bool, string, string)

The Assert method displays a failure message (it is displayed on the application failure and allows users to abort execution, ignore the failure or retry the code that caused the failure) if the condition is false. Two overloads allow displaying custom information by specifying one or two accompanying messages (these messages can be set by the string parameters - this is done to allow developers to display extra information about the assertion fail).

To describe how the messages are displayed, we'll demonstrate several examples to you. The first shows the results of assertion without any extra messages. Such an assertion can be made using code like the following:

Full article...

Other Resource

... to read more articles, visit

Debugging in .NET