Reputation:
What is the best practice regarding Debug.Print
statements?
Should I litter my class methods with Debug.Print
statements or should I avoid Debug.Print
altogether?
If Debug.Print
statements are acceptable should I consider using Trace.Print
or EventLog
?
Are Debug.Print
statements necessary with unit tests? Can I avoid Debug.Print
statements with well written unit tests?
Upvotes: 5
Views: 3248
Reputation: 57919
Debug.Print
is acceptable, not least because they'll be compiled out in your release builds. "Littering" your code with it, however, doesn't sound especially productive or useful.
You can add it while debugging a particular area of code. Once you identify the defect, you can write a unit test to cover the case, fix the bug, and then remove the call to Debug.Print
.
What I sometimes use and leave in the code base is Debug.Assert
-- it is like a built-in breakpoint if my application is not in an expected state, which is just an added safety net while doing both automated and manual testing.
Debug.Print
is not necessary in unit tests, and should not be added for the sake of unit tests.
Upvotes: 5
Reputation: 1876
I've never used Debug.Print or Trace.Print. I do write a good amount of unit tests. I've never found that I need to use the Debug or Trace objects with the unit tests that I write. I do try to unit test as much as possible, however.
Upvotes: 0
Reputation: 22379
You don't need Debug.Print at all with unit tests! The point of unit tests is that you automatically get an indication whether the test succeeded or failed, you don't need to look for debug prints for that.
NUnit is an easy-to-use unit testing library.
As for tracing or logging, you don't need to litter your code with debug prints for that either. Try interception with Castle Windsor or other frameworks that support AOP.
Upvotes: 2