.net - 在单独运行或在 reSharper 或 TeamCity 中运行的 nUnit 中使用 Console.Out.WriteLine 与 Trace.WriteLine

Question

我依稀记得在 nUnit 中可能在 reSharper 或 TeamCity 的上下文中阅读了关于在 Console.Out.WriteLine 上使用 Trace.WriteLine 的“某事”“某处”，但我不记得细节。

因此，问题是在 nUnit 单独运行的情况下，还是在 reSharper/TeamCity 中使用其中一个是否有任何好处，有什么区别(如果有)以及您个人会使用什么？

目前我的立场是 Trace.WriteLine 不仅因为我模糊地记得我可以梦想的东西，而且我觉得单元测试中的跟踪更多的是诊断任务而不是输出任务。

Answer 1

就个人而言，我并不热衷于在单元测试中嵌入跟踪(使用您提到的任何一种方法)。如果单元测试需要这样做，则很可能表明您的单元测试过于复杂。如果您需要通过单元测试跟踪逻辑，则应在整个测试中使用断言以编程方式检查预期行为是否正在发生，从而消除对文本跟踪输出的需要。

但是，您需要务实 - 有时这样做很有用。使用任何一种方法(或其他类似 Debug.WriteLine 的方法)都可以，但是您使用哪种方法确实给了您一些灵活性。

如果您有大量输出跟踪的测试，则在一次运行中运行所有测试时，您可以获得大量跟踪输出。在 NUnit 中，您可以在选项页面中对其进行过滤:



四个选项做以下ref :

标准输出 :捕获写入 Console.Error 的所有输出。

错误输出 :捕获写入 Console.Error 的所有输出。

跟踪输出 :捕获所有写入 Trace 或 Debug 的输出。

日志输出 :捕获写入 log4net 日志的输出。 NUnit 捕获错误级别或更高级别的所有输出，除非为 DefaultLogThreshold 指定了另一个级别。测试程序集或项目的配置文件中的设置。

通过关闭这些选项，您可以单独禁用发送到四种不同日志记录方法的跟踪输出，使您能够过滤测试跟踪。

我不知道 ReSharper 的测试运行器中有任何类似的设置。

同样值得考虑的一件事是文本输出可能会产生副作用。我最近遇到 NUnit 崩溃，因为某些输出包含 XML 文件中的非法字符 - NUnit 生成一个作为我们自动构建的一部分。

编辑 :

@Bronumski:我能看到使用一种方法与另一种方法的唯一真正区别是输出的消耗方式。

某些工具会捡起来 Debug跟踪(例如 DebugView)但不是 Console输出。此外，您可以禁用 Trace通过配置(在 app.config 中)在运行时输出，但不是 Console输出。这只会在您必须用跟踪来装饰真实(即不测试)代码时才重要 - 在运行时记录大量文本可能会很昂贵，因此如果可以关闭它是有益的，除非您真的需要它来诊断某物。

此外，在使用 NUnit 时，如果您有太多的日志记录需要浏览，您可以有选择地相互独立地关闭它们。