Nunit: 将文件附加到测试结果

您提到的方法是 Microsoft 测试框架中 TestContext 类的一部分。 NUnit 也有一个同名的类，但它与 MsTest 类没有关系，也没有这样的方法。 NUnit 中没有将文件附加到输出的工具。

谢谢查理。
但是 AddResultFile 方法将来会添加到 NUnit 吗？
这个方法真的很有帮助。

目前没有这方面的计划。 如果您想将此问题更改为对此类功能的请求，我们可以这样做并重新打开它。

如果是这样，您应该更详细地解释它是如何工作的。 文件是如何创建的，它们存储在哪里等等。您是要求 NUnit 实际创建文件还是只是保留对它们的引用？

当然，我们必须接受这个想法，优先考虑它并安排发布。

谢谢你的回复查理。
如果将该方法添加到 NUnit 中，那就太好了。
它就像微软测试框架中 TestContext 类的 AddResultFile 方法一样工作。
类似于将测试结果（文件 html 测试结果或屏幕截图）链接到 VS 中测试资源管理器中的测试输出。 您可以看到如下屏幕截图。

谢谢你的想法。 我会重新打开这个。

然而，为了更进一步，我们必须弄清楚它是如何为 NUnit 本身工作的，而不仅仅是适配器。 我将其标记为一个想法，这就是我们所说的定义不够明确的东西，无法将其视为未来的功能。 也许其他人会加入建议。

我们需要考虑的事情：

• 这将如何在 XML 结果中显示
• 我们能否以某种方式将所有这些打包，以便将结果和附件保存在一起？
• 如果有的话，NUnit 控制台会用它做什么。
• NUnit gui 会以某种方式显示它吗

这个功能是必须的。
我们正在使用 NUnit 和 Selenium 运行我们的自动化行为测试。 如果测试失败，我们喜欢在测试结果中附上浏览器的屏幕截图：这对修复测试很有帮助。
为此，我们不得不使用 Microsoft 的测试框架，但它不如 NUnit 强大（程序集或类级别的属性，通用测试类......）。 所以我们期待 NUnit 中的这个功能。

我正在将其更改为需要设计的功能，这比想法更可靠。 我们仍然需要解决我之前评论中列出的问题。

我想它要么在xml中序列化文件，要么在它之外保留一个引用的目录。 一个导致大量 xml、普遍缓慢以及需要特定解释器的文件，另一个导致文件与结果分离的可能性，并且引用被破坏。

哪个是邪恶的较小的？ 我觉得对于前者，痛苦会超过将所有内容都打包的好处 - 并且“希望可用”相关链接就足够了。

• 如果有的话，NUnit 控制台会用它做什么。
• NUnit gui 会以某种方式显示它吗

对于 GUI，类似上面的界面看起来已经足够好了，只是附加文件的超链接。 控制台 imo 应该在失败测试消息中通知用户一个文件可用，以及它的位置。

我想这将需要有人提交 PR，一旦设计完成 - @fredgate ，你有兴趣吗？ 😄

我们应该看看 MSTest 如何存储文件。 我希望 Visual Studio 扩展需要一个指向驱动器上文件的链接。

似乎在 XML 中的引用是要走的路。 对于 NUnit，逻辑初始位置是工作目录，默认情况下就是 XML 所在的位置。 这解决了我上面的前两点。

回答我的其他观点：

• 我猜控制台只会列出带有路径的附件，就像它对结果所做的一样。
• gui 可以有某种菜单或面板来列出附件。 如果为特定文件类型定义了默认应用程序，它可以显示它们。

似乎是一个很好的功能，我倾向于将其提高到正常优先级。

@rprouse你还记得 Gallio 是如何处理附件的吗？

附件元素在属性和元素方面需要包括什么？ 像这样的东西？

<attachments>
    <attachment  description="Final screen shot">ScreenShot.jpg</attachment>
    ...
</attachments>

我假设它是产生它的测试的子代，所以我们有这些信息。 用户可能希望包含多个屏幕截图，因此需要进行描述。 还要别的吗？

附加东西的语法是什么？ 我们应该使用 TestContext 吗？ 是否应该有一种方法将它与断言相关联，以便在失败时自动创建附件？

有人想为此编写规范吗？

似乎是一个很好的功能，我倾向于将其提高到正常优先级。

👍

@rprouse你还记得 Gallio 是如何处理附件的吗？

不，我从未使用过附件。 我喜欢你的 XML 格式。 就个人而言，我认为我们应该从从 TestContext 添加附件开始，因为它是更简单的途径。 然后我们可以评估是否要将其扩展到断言。

所以TestContext.CurrentContext.AddAttachment ？

(string path)和(string path, string description)重载？

也许我们已经有了规范！

请提高此功能的优先级。 附上 UI 屏幕截图对我们的测试结果摘要非常有帮助。 这些附件是否可以在 VSTS（Visual Studio Team Services）内的构建结果中使用？
非常感谢你查理

我认为这是一个很好的功能，我将在 TeamCity 中将附件作为构建工件发布

由于@rprouse已经提出了这一建议，因此我将其提升为正常优先级。 但是请注意，低优先级和正常优先级的项目有时必须等待某人受到启发来实施它们——NUnit 提交者或贡献者。 关于何时完成，这更像是个人决定而不是团队决定。

我希望没有人忘记这件事。 这将是一个非常有用的功能。

我认为先前的评论解决了所有设计问题，因此我将取消设计标签并将实施问题添加到 Backlog。

与其说是我们忘记了这一点，不如说是我们有很多事情正在发生。 正如我在之前的评论中提到的，像这样的正常优先级项目没有安排在我们的发布计划中。 取决于某些团队成员或外部贡献者是否对他们感兴趣并接受它。 希望将其添加到待办事项中会激励某人站出来。 根据您的技能，那可能是您！ 😄

很棒的功能！ 将不胜感激。 希望有人尽快实现这个😄

我刚刚在 #2152 中为实现这一点所需的框架功能做了一个 PR。 鉴于有几个人在跟踪这个问题，一旦我们决定在那里做什么，我计划将这个问题转换为 Epic 和 Track runner 支持。

这是我的想法：

VS 适配器
这是 MSTest 的一项功能，因此 VS 适配器框架已经具有显示附加文件的功能。 只需要追踪如何插入它。🙂

控制台/NUnitLite
我在这里心情复杂。 对于错误/警告测试，显示附件的文件路径/描述和结果是有意义的。 通过测试的附件怎么样？ 我们应该有一个“信息”输出来显示这些吗？ 所以控制台运行器会有三种类型的输出 - 信息/警告/错误？

图形用户界面/Xamarin
这两个最终都应该支持这一点，但我认为这不是一个高优先级。 我会创建问题，但不会将它们附加到这个 Epic - 它们可以在有需求/时间允许的情况下完成。

团队城市
@NikolayPianikov - 你说你对此感兴趣。 也许值得您跟踪 #2152。 🙂

对以上所有的想法？ @nunit/framework-team ？ 一旦我们决定了下一步，我就会提出个别问题。

@ChrisMaddock问题也可能是设计问题，因此您可以做一个说“弄清楚如何在 gui 中支持附件”的问题 - 对于您不确定的任何其他问题也是如此。

对于控制台运行程序，我们目前不会显示所有测试，尽管可以这样做。 任何详细报告都可以由扩展或自定义 XSL 转换处理。 对于愿意进行 XSL 编码的任何人来说，后者的实现是微不足道的。 😄 这可能是一个贡献转换。

NUnitLite 很棘手，因为我们想让它保持非常轻量。 然而，假设用户会以一种智能的方式命名他们的附件并将它们全部放在同一目录中，因此它们应该很容易找到。 事实上，这也适用于控制台运行器
我认为 gui 的自然事情是显示附件的名称和描述以及有关测试结果的所有其他内容。 如果用户安装了可以打开文件的适当应用程序，我们可以将其设为链接。

一旦我们有了附件，我认为很容易将它们添加到我们从适配器传递给 Visual Studio 的结果中。

我创建了https://github.com/nunit/docs/issues/197和https://github.com/nunit/nunit3-vs-adapter/issues/332来介绍接下来的步骤。

关于运行器支持 - 如果当前唯一的调用是与 VS 适配器集成，那么我现在倾向于在那里实现它。 这是一个更适合图形运行器的功能，如果人们有需要，那么将来总是可以添加 cli 和其他运行器支持。

@ChrisMaddock我很想看到控制台运行器的附件支持。

@kdubau - 完美的时机！ 😄 在这种情况下，你希望它看起来像什么？ 你的用例是什么？

我可以想象添加一个“附件”文本块来测试失败/警告、列表描述和文件路径。 我争论不这样做的一个原因是，我不相信许多用户会想要从他们的 shell 复制/粘贴文件路径，以找到相应的文件。 你会不同意吗？

要考虑的另一个问题是，控制台当前仅显示失败/警告测试，而不是所有测试。 我们是否应该创建第三个结果列表（“信息”？）来显示所有通过的带有附件的测试？

也许控制台运行程序只显示失败测试的附件实际上是可以的，因为这可能是控制台运行中所有有趣的内容。 我正在想象有关失败的相关日志文件，等等。

@kdubau我建议您在 nunit-console 存储库中创建一个新问题，而不是在此处进行描述。

@ChrisMaddock @CharliePoole我可能误解了这里的上下文。 我只对输出 XML 中引用的附件感兴趣 - 不需要在控制台输出中实际显示附件信息。 我的用例是让我的 CI 系统（Visual Studio Team Services）能够将 XML 中列出的附件作为构建工件上传（因此它只需要引用本地磁盘上的文件）。

我担心通过控制台运行器运行测试不会在 XML 中包含附件，但在进一步阅读后，我认为这不是问题。 如果我错了，请纠正我:)

@kdubau - 你说得对。 🙂 #2152 刚刚合并，支持结果xml中的附件。 如果一切按计划进行，这将成为下周发布的 NUnit 3.7 的一部分。

是的……如果我们需要控制台中的“支持”，那将意味着要做的不仅仅是保存来自框架的 XML。 对于 nunit3 适配器，我猜@ChrisMaddock正在定义这意味着什么。

嘿伙计们，这项工作已经完成还是更多待定？ 我找不到任何未解决的问题或与之相关的 PR。

如果我遗漏了一些东西，但我的测试附件仍然没有像我预期的那样出现在 VS 测试资源管理器中，我深表歉意。 我正在使用 NuGet 的 NUnit3TestAdapter 3.8.0 和 API TestContext.AddTestAttachement(file)但我在测试资源管理器中没有看到附件。 我期待这样的事情：

我的期望错了吗？

@kdubau - 不，这应该在 NUnit v3.7 和 NUnit3TestAdapter 3.8 中发布。 有关实现，请参阅https://github.com/nunit/nunit3-vs-adapter/issues/332 。 这个问题仍然悬而未决，因为我仍然没有时间添加所需的两句话文档......😱

如果它不起作用，我将首先在 NUnit 控制台中运行您的测试 - 并查看您的附件是否正确记录在结果 xml 文件中。 如果没有，在这个 repo 中打开一个问题，如果是，在适配器 repo 中打开一个问题，我们可以进一步调查。 🙂

@ChrisMaddock好的，问题已创建https://github.com/nunit/nunit3-vs-adapter/issues/373

感谢@kdubau 的激励，我终于记录了这个功能，并且可以关闭这个 Epic。 😄