I am debugging with breakpoints and I realize the assert call? I thought it was only for unit tests. What does it do more than breakpoint? Since I can breakpoint, why should
You should use it for times when you don't want to have to breakpoint every little line of code to check variables, but you do want to get some sort of feedback if certain situations are present, for example:
Debug.Assert(someObject != null, "someObject is null! this could totally be a bug!");
Assert can help you give separate messaging behavior between testing and release. For example,
Debug.Assert(x > 2)
will only trigger a break if you are running a "debug" build, not a release build. There's a full example of this behavior here
In a debug compilation, Assert takes in a Boolean condition as a parameter, and shows the error dialog if the condition is false. The program proceeds without any interruption if the condition is true.
If you compile in Release, all Debug.Assert's are automatically left out.
First of all Assert()
method is available for Trace
and Debug
classes.
Debug.Assert()
is executing only in Debug mode.
Trace.Assert()
is executing in Debug and Release mode.
Here is an example:
int i = 1 + 3;
// Debug.Assert method in Debug mode fails, since i == 4
Debug.Assert(i == 3);
Debug.WriteLine(i == 3, "i is equal to 3");
// Trace.Assert method in Release mode is not failing.
Trace.Assert(i == 4);
Trace.WriteLine(i == 4, "i is equla to 4");
Console.WriteLine("Press a key to continue...");
Console.ReadLine();
Run this code in Debug mode and then in Release mode.
You will notice that during Debug mode your code Debug.Assert
statement fails, you get a message box showing the current stack trace of the application. This is not happening in Release mode since Trace.Assert()
condition is true (i == 4)
.
WriteLine()
method simply gives you an option of logging the information to Visual Studio output.
Assert also gives you another opportunity to chuckle at Microsoft's UI design skills. I mean: a dialog with three buttons Abort, Retry, Ignore, and an explanation of how to interpret them in the title bar!
From Code Complete
8 Defensive Programming
8.2 Assertions
An assertion is code that’s used during development—usually a routine or macro—that allows a program to check itself as it runs. When a assertion is true, that means everything is operating as expected. When it’s false, that means it has detected an unexpected error in the code. For example, if the system assumes that a customer-information file will never have more than 50,000 records, the program might contain an assertion that the number of records is less than or equal to 50,000. As long as the number of records is less than or equal to 50,000, the assertion will be silent. If it encounters more than 50,000 records, however, it will loudly “assert” that there is a error in the program.
Assertions are especially useful in large, complicated programs and in high-reliability programs. They enable programmers to more quickly flush out mismatched interface assumptions, errors that creep in when the code is modified, and so on.
An assertion usually takes two arguments: a boolean expression that describes the assumption that’s supposed to be true and a message to display if it isn’t.
(…)
Normally, you don’t want users to see assertion messages in production code; assertions are primarily for use during development and maintenance. Assertions are normally compiled into the code at development time and compiled out of the code for production. During development, assertions flush out contradictory assumptions, unexpected conditions, bad values passed to routines, and so on. During production, they are compiled out of the code so that the assertions don’t degrade system performance.