Using Console.Out.WriteLine vs Trace.WriteLine in nUnit either running in isolation or within reSharper or TeamCity

I vaguely remember reading "something" "somewhere" about using Trace.WriteLine over Console.Out.WriteLine in nUnit possibly in the context of reSharper or TeamCity but I cannot remember the details.

Therefore the question is either in the context of nUnit running separately or within reSharper/TeamCity is there any benefit of using one over the other, what are the differences if any and what would you personally use?

Currently my stand point is Trace.WriteLine not only because I vaguely remember something which I could have drea开发者_如何学Gomt up but that I feel that tracing in a unit test is more of a diagnostics task than an output task.

Personally, I am not keen on embedding tracing in unit tests (using either method you mention). If a unit test requires this, it is most likely a sign that your unit test is too complex. If you need to trace logic through the unit test, you should use asserts throughout the test to programmatically check that the expected behaviour is occurring, removing the need for the textual tracing output.

However, you need to be pragmatic - it is useful to do this sometimes. Using either method (or something else like Debug.WriteLine) is fine, but which one you use does give you some flexibility.

If you have a lot of tests that output tracing, you can get a lot of tracing output when you run all of your tests in a single run. Within NUnit, you can filter this in the options page:

The four options do the following ^ref:

• Standard Output: Captures all output written to Console.Error.
• Error Output: Captures all output written to Console.Error.
• Trace Output: Captures all output written to Trace or Debug.
• Log Output: Captures output written to a log4net log. NUnit captures all output at the Error level or above unless another level is specified for the DefaultLogThreshold setting in the configuration file for the test assembly or project.

By turning off these options, you can individually disable the output of tracing sent to the four different logging methods, enabling you to filter your test tracing.

I am not aware of any similar setting in ReSharper's test runner.

_{One thing also worth considering is that the text output can have side effects. I recently encountered NUnit crashing because some output contained characters that were illegal in an XML file - NUnit produces one as part of our autobuild.}

EDIT:

@Bronumski: The only real difference I can see of using one method over another is the way the output is consumed.

Certain tools will pick up Debug tracing (eg. DebugView) but not Console output. Also, you can disable Trace output at runtime via configuration (in app.config), but not Console output. This will only matter though if you have to decorate real (ie. not test) code with tracing for your tests - logging lots of text at runtime can be costly and so is beneficial if it can be turned off unless you really need it to diagnose something.

Additionally, when using NUnit, you can selectively turn them off independently of each other if you have too much logging to wade through.

Unit tests are not production code. No reason why you can't you Console if you want to. If you want to use Trace, that's fine too, but it's a bit more work to set up. I'm not familiar with TeamCity, so I can't help you there.

Debug Class provides a set of methods and properties that help debug your code. If you use methods in the Debug class to print debugging information and check your logic with assertions, you can make your code more robust without impacting the performance and code size of your shipping product. In Visual Studio 2005 projects, creating a debug build enables Debug.

You can use the properties and methods in the Trace class to instrument release builds. Instrumentation allows you to monitor the health of your application running in real-life settings. Tracing helps you isolate problems and fix them without disturbing a running system. In Visual Studio 2005 projects, Trace is enabled by default for both release and debug builds, so code is generated for all trace methods in both release and debug builds. Therefore, you can use Trace to instrument release builds.

I found this excerpt from here if it helps:

http://www.interviewcorner.com/Answer/Answers.aspx?QuestionId=268&MajorCategoryId=1&MinorCategoryId=16

EDIT: Located some more interesting information mentions trace using a multicast, does that imply that anything that implements it will capture the trace write line?

Read and give feedback please:

http://www.drdobbs.com/184405769;jsessionid=SFAYCN2R2Y3L5QE1GHRSKH4ATMY32JVN