在 nUnit 中使用 Console.Out.WriteLine 与 Trace.WriteLine，无论是独立运行还是在 reSharper 或 TeamCity 中运行
我依稀记得读过关于在 nUnit 中使用 Trace.WriteLine 而不是 Console.Out.WriteLine 的“某事”“某处”，可能是在 reSharper 或 TeamCity 的上下文中，但我不记得细节了。
因此，问题是无论是在 nUnit 单独运行的情况下还是在 reSharper/TeamCity 中使用其中一种相对于另一种是否有任何好处，如果有的话，有什么区别以及您个人会使用什么？
目前我的立场是 Trace.WriteLine ，不仅因为我隐约记得一些我可能梦想到的东西，而且我觉得单元测试中的跟踪更多的是诊断任务而不是输出任务。
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 dreamt up but that I feel that tracing in a unit test is more of a diagnostics task than an output task.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就我个人而言，我不热衷于在单元测试中嵌入跟踪（使用您提到的任何一种方法）。如果单元测试需要这样做，则很可能表明您的单元测试过于复杂。如果需要通过单元测试跟踪逻辑，则应在整个测试中使用断言以编程方式检查是否发生了预期行为，从而无需文本跟踪输出。
然而，你需要务实——有时这样做是有用的。使用任一方法（或诸如 Debug.WriteLine 之类的其他方法）都可以，但使用哪一种方法确实可以提供一定的灵活性。
如果您有大量输出跟踪的测试，则当您在一次运行中运行所有测试时，您可以获得大量跟踪输出。在 NUnit 中，您可以在选项页面中对其进行过滤：
这四个选项执行以下操作 ref：
DefaultLogThreshold设置指定了另一个级别。通过关闭这些选项，您可以单独禁用发送到四种不同日志记录方法的跟踪输出，从而使您能够过滤测试跟踪。
我不知道 ReSharper 的测试运行程序中有任何类似的设置。
还值得考虑的一件事是文本输出可能会产生副作用。我最近遇到 NUnit 崩溃，因为某些输出包含 XML 文件中非法的字符 - NUnit 生成一个作为我们自动构建的一部分。
编辑：
@Bronumski：我能看到的唯一真正的区别使用一种方法而不是另一种方法的关键在于输出的消耗方式。
某些工具将获取
Debug跟踪（例如 DebugView），但不会获取Console输出。此外，您可以通过配置（在 app.config 中）在运行时禁用Trace输出，但不能禁用Console输出。仅当您必须通过测试跟踪来装饰真实（即非测试）代码时，这才有意义 - 在运行时记录大量文本可能成本高昂，因此如果可以将其关闭，则是有益的除非你真的需要它来诊断某些事情。此外，在使用 NUnit 时，如果您有太多日志记录需要处理，您可以有选择地相互独立地关闭它们。
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:
DefaultLogThresholdsetting 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
Debugtracing (eg. DebugView) but notConsoleoutput. Also, you can disableTraceoutput at runtime via configuration (in app.config), but notConsoleoutput. 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.
单元测试不是生产代码。如果你愿意的话，你没有理由不能使用控制台。如果您想使用 Trace，也可以，但设置工作要多一些。我对 TeamCity 不熟悉，所以无法为您提供帮助。
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 类中的方法来打印调试信息并使用断言检查逻辑，则可以使代码更加健壮，而不会影响交付产品的性能和代码大小。在 Visual Studio 2005 项目中，创建调试版本可启用调试。
您可以使用 Trace 类中的属性和方法来检测发布版本。仪器允许您监控在现实生活设置中运行的应用程序的运行状况。跟踪可帮助您隔离问题并修复它们，而不会干扰正在运行的系统。
在 Visual Studio 2005 项目中，默认情况下为发布和调试版本启用跟踪，因此会为发布和调试版本中的所有跟踪方法生成代码。因此，您可以使用 Trace 来检测发布版本。
如果有帮助的话，我从这里找到了这段摘录：
http ://www.interviewcorner.com/Answer/Answers.aspx?QuestionId=268&MajorCategoryId=1&MinorCategoryId=16
编辑：找到一些更有趣的信息提到使用多播的跟踪，这是否意味着任何实现它的东西都会捕获跟踪写入行？
请阅读并提供反馈：
http://www.drdobbs.com/184405769;jsessionid=SFAYCN2R2Y3L5QE1GHRSKH4ATMY32J越南
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