C＃：最佳实践Debug.Print

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.