Nunit: 在 .NET CLI 和 .NET Core 中支持 `dotnet test`

创建于 2016-03-23  ·  49评论  ·  资料来源: nunit/nunit

我们已经可以使用控制台应用程序使用 nunitlite 使用dotnet run (例如在这个chessie commit 中)运行 nunit 测试。 并且有效(忘记dnxcore50 atm,应该是netstandard

但是对于 .NET CLI ( https://github.com/dotnet/cli ) 中的测试执行,命令是dotnet test

dotnet test应该从 ide(参考 dotnet/cli#1376 )那里获得有关发现/调试/等的支持

这是当前的前进方向,不推荐使用 dnx(应该关闭 #927)并且 aspnet 和 dnx 正在转移到 .NET CLI

dotnet-test-nunit需要一个新库dotnet test

dotnet-test-xunit (参考 https://github.com/xunit/coreclr.xunit/pull/1)

xunit 测试项目的示例project.json (https://github.com/dotnet/cli 内的引用测试)是

{
    "version": "1.0.0-*",
    "dependencies": {
        "NETStandard.Library": "1.5.0-rc2-23911",
        "xunit": "2.1.0",
        "dotnet-test-xunit": "1.0.0-dev-91790-12"
     },
     "frameworks": {
         "netstandardapp1.5": { }
     },
     "testRunner": "xunit"
}

testRunner属性由dotnet test (参考)读取并使用dotnet-test-{testRunner}

/cc @piotrpMSFT @livarcocc获取信息,因为他们在 .NET CLI 和 dotnet-test、dotnet-test-

我可以帮你解决这个问题,如果你没问题, @piotrpMSFT说去(我认为它是稳定的 atm,但最好确定):微笑:

done enhancement high

最有用的评论

它还没有准备好迎接黄金时段,但我已经在控制台和 Visual Studio 中运行了 NUnit .NET Core 测试。 还有几个问题需要解决之前,我得到一个字母,但是我们现在近的辛勤工作完成,它是倒在细节。

在解决一些问题后,我将发布有关如何使用 CI 构建进行测试的详细信息。 如果人们可以踢轮胎并帮助我找到问题,我将不胜感激。

这是一个屏幕截图。

image

所有49条评论

在我们继续#927 之前,我们一直在等待 .NET Core 安定下来,这就是为什么它没有更新新的标题和信息。 我计划在继续之前等待可能在 //build 上发布的任何公告,但我们将不胜感激我们能得到的任何帮助。 我的计划是在今年夏天的 3.4 版本中开始为更多平台提供更完整的支持,包括 .NET Core、UWP 和 Xamarin。

你在这里提供了一个写得很好的总结,所以我将关闭 #927 并使用这个问题进行跟踪。 如果你想帮助解决这个问题,那么我们可以协调,但我欢迎你的帮助。

此过程的第一步是创建一个 PCL 驱动程序/代理,它可以加载和执行测试,而无需与 NUnit 框架的特定版本(如 NUnitLite 和当前的 Xamarin 运行程序)紧密绑定。 它仍处于起步阶段,但正在进行的工作是在nunit.portable.agent项目中。

@piotrpMSFT@livarcocc可以提供的任何帮助或建议也将不胜感激 :smile:

@rprouse我在 CLI 上有一个错误,用于编写关于 dotnet 测试和运行程序之间的交互和要求的更好的文档。 我会在今天或明天完成它,我会在这里放一个链接。

这是跟踪它的错误: https :

这是怎么回事? 我很想使用它,而且 dotnet cli 生态系统似乎正在稳定下来。

我正在取得一些进展,但在 RC2 下降之前我不想做太多。 我厌倦了跟上变化的步伐 :smile:

我可以在这里帮助任何人吗? 这是完成我们某些端口(如 StackExchange.Redis)的阻止程序。

@NickCraver我绝对可以使用一些帮助,第一次阅读通信协议并没有让事情变得非常清楚:微笑:

第一步是决定我们将如何处理这个问题。 我们目前有针对 .NET Core 的可移植构建,但它是有限制的。 我正在考虑创建框架的核心构建,但不确定我是否需要或应该。

然后我需要看看为dotnet命令创建测试扩展需要什么。

最后,我希望 nunit 引擎能够启动并与核心 nunit-agent 通信,以便 nunit3-console 可以运行 .NET Core 单元测试。 我一直在做这方面的工作,但仍有很多工作要做。

您想如何提供帮助?

@rprouse我认为您必须拥有一个核心版本才能跨平台使用,这是一个关键功能。

考虑到剩下的工作量,老实说,我不确定我们可以投入多少时间与在其他地方投资相比。 现在,我需要为许多等待构建库和应用程序的下游人提供库。 我不想这么说,但考虑到这里的滞后与今天可用的相比,我认为我们必须完成将所有内容移植到 xUnit,否则成百上千的开发人员正在等待这里的发布链受阻。

在我们稳定并且时间允许之后,我会尝试重新访问这个,但是(如果我错了,请纠正我)目前我们正在谈论在我之前剩下的几周工作(通过你的帖子) d 能够使用它来运行我希望已完成的准备发货的库端口。 从作者职责的角度来看,我需要先解除对我的人的封锁,然后尽可能地帮助上游。

@NickCraver与其花费精力移植到 xUnit,不如创建一个命令行 NUnitLite 运行程序来运行您的 .NET Core 测试可能更容易。 这不是一个完美的解决方案,但可能是最少的工作。 它有点过时了,但我在使用 NUnit 3 测试 .NET Core 时写了一篇关于如何做到这一点的博客。

我正在为一些个人项目这样做,而且它很实用。

我很乐意帮助在那里构建适当的 dotnet-test-nunit。 相信很多人都会受益。 协议中定义的大部分契约已经在辅助库中实现。 如果我们有一个可以工作的 xplat nunit runner,这应该没什么工作。

将其分为两个阶段是否有帮助 - 一种“快速而肮脏,可能有一些糟糕的黑客,但至少让我们在那里得到一些东西”发布,然后是更成熟的集成?

(例如,刚准备使用 netstandard1.3 的 TFM 构建测试将大大有助于为 Noda Time 解除阻塞。)

@jskeet@NickCraver今天你可以通过 NUnitlite“hack”使用 NUnit,正如@rprouse 所建议的,我已经为 Npgsql 做了一段时间了,它运行良好。 这不是完美的解决方案,但绝对应该让你们畅通无阻。

@roji :这与dnxcore50 (我已经将它与 Noda Time 一起使用了一段时间)-但是使用netstandard1.3 ,对 NUnit 和 NUnitLite 的依赖是无效的。

@jskeet我的测试项目针对 netcoreapp1.0 并依赖于 Nunit+NUnitLite 3.2.1。 我有"imports" : [ "dotnet54" ] ,它就像一个魅力......

@roji :谢谢你...手指交叉...

@roji :我在实际运行测试时仍然遇到问题-您能否链接到您在测试项目中执行此操作的位置,作为要遵循的示例?

@jskeet确定,给你: https :

@jskeet导入也应该适合你。 RC2 更改了一些内容,因此我将重写我的博客文章,介绍如何在考虑 RC2 的情况下使用 NUnit 3 进行测试,并将代码发布到 GitHub。 完成后我会在这里添加一个链接,希望今天早上(美国东部标准时间)。

@piotrpMSFT你能帮我节省一些时间并指向我创建dotnet-test-nunit的帮助程序库吗? 我可以搜索,但目前我正在追寻几件事,因此将不胜感激。 我相信你也很忙,所以如果你手头没有它,不要花时间在上面,我会找到它。

我已经为任何感兴趣的人发布了一篇更新的博客文章使用 NUnit 3 测试 .NET Core RC2

@jskeet您确实需要 project.json 中的导入语句。 新的 .NET Core 模板中默认添加,但升级时需要添加。

对于控制台运行程序中的 project.json;

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

或在集会中;

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

升级到 RC2 时,在我的路径中放置旧的 DNX 东西也让我感到困扰。 要检查的东西。

@rprouse :谢谢; 我现在可以构建,并且测试在 Windows 上运行。 在 Linux 上,我看到“未将对象引用设置为对象的实例”。 dotnet run上的消息,我需要进一步调查。 将尝试您的最小样本,看看是否有同样的问题......

@jskeet ,我们在 Windows 和 Linux 上都使用这种方法没有问题。 有关示例,请参见此处此处

@oschwald :是的,看起来“对象引用未设置...”的问题是一个非常独立的依赖问题。 很遗憾,错误消息如此无用(甚至没有堆栈跟踪) - 我正在深入研究它。

@jskeet有几个原因,这是您的原因吗? https://github.com/dotnet/cli/issues/3075

@NickCraver :不 - 我已经成功完成了 dotnet 恢复。

就我而言,我有一个 project.json 文件,该文件在不依赖于另一个项目的情况下工作,但它失败了。 我需要花更多的时间来想出一个完整的再现。

@jskeet Gotcha - 相关: https : Slack 频道非常适合project.json实时调试,加入示例,您通常可以很快上手。 对于 Slack,#general 和 #dotnet-core 频道非常活跃,很多人都在经历这个并帮助下一个人。

嗯......现在它正在工作。 有可能它_是@NickCraver报告的相同问题,而我只是dotnet restore错误的项目来修复它。 无论如何,我现在正在 Linux 上运行 Noda Time 测试,所以 :) 谢谢大家。

@piotrpMSFT 是我对指针的请求,我已经找到了我需要的一切并开始工作。

我在 nunit/dotnet-test-nunit#1 为dotnet-test-nunit runner 添加了一个初始 PR

它探索并运行测试,但仍需要一些工作、清理和测试。 如果有人想使用它,我将使构建工件的 NuGet 提要更易于访问。

如果有人对如何在 Visual Studio 加载 NuGet 包时对其进行调试有任何想法,我可以使用一些帮助。 到目前为止,它还没有在 Visual Studio 中运行,但这可能是设置问题。

@rprouse :如果有用的话,我很高兴看到 Noda Time 如何处理它。 如果有什么特别想让我检查的,请告诉我。 感谢您的工作!

它还没有准备好迎接黄金时段,但我已经在控制台和 Visual Studio 中运行了 NUnit .NET Core 测试。 还有几个问题需要解决之前,我得到一个字母,但是我们现在近的辛勤工作完成,它是倒在细节。

在解决一些问题后,我将发布有关如何使用 CI 构建进行测试的详细信息。 如果人们可以踢轮胎并帮助我找到问题,我将不胜感激。

这是一个屏幕截图。

image

@rprouse :CI 构建有什么进展吗? 绝对热衷于踢轮胎; Noda Time 使用了 _reasonable_ 数量的 NUnit 功能,所以无论如何它应该是一个好的开始。 真的很期待能够再次在 VS 中运行测试。 (希望 Roslyn 的 NCrunch 和 CodeRush 也开始支持它……)

@jskeet和其他有兴趣在我发布 alpha 之前帮助我测试的人,我已经更新dotnet-test-nunit分支上的演示存储库以使用新的dotnet-test-nunit runner。

请在nunit/dotnet-test-nunit 存储库中报告问题。

高级指令是;

更新: dotnet-test-nunit现在可作为 NuGet 上的 alpha 版本使用,请选择Include prereleases 。 您不再需要更新nuget.config文件。

dotnet-test-nunit仍在开发中,因此您需要将NuGet.Config文件添加到您的解决方案中,以便从 NUnit CI NuGet 源下载 NuGet 包。

您的测试项目中的project.json应如下所示;

项目.json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

这里感兴趣的是对dotnet-test-nunit的依赖。 随意使用以-CI结尾的最新预发布版本,这是来自主分支的最新版本。 请注意, NUnitWithDotNetCoreRC2依赖项是被测项目。

我添加了"testRunner": "nunit"来指定 NUnit 3 作为测试适配器。 我还必须添加到测试适配器和 NUnit 的导入中才能解决。 最后,我不得不添加runtimes 。 如果有人可以解释为什么我需要这样做,请告诉我。

现在可以使用 Visual Studio 测试资源管理器或通过从命令行运行dotnet test来运行测试。

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

警告

正如我所说,这仍在开发中。 上面列出的dotnet-test-nunit版本 3.3.0.39-CI 有一个错误,当它尝试保存TestResult.xml文件时会抛出ArgumentException

另请注意, dotnet命令行会吞下空行并且不适用于颜色。 NUnit 测试运行器的输出是彩色的,但您不会看到它。

“空线吞咽”部分是一个已知错误: https :

感谢@jskeet的链接,看起来颜色也是一个已知的错误,dotnet/cli#1977

ArgumentException已在3.3.0.49-CI修复。 我将使用修复程序更新我的上述说明。 另一个悬而未决的问题是,我目前没有向运行程序提供测试行号,因此单击 Visual Studio 测试资源管理器中的测试不会将您带到代码。

我说没有命令行参数支持是对的,比如--where等? (我完全理解现在还为时尚早——只是想检查这是否是我应该能够做的事情。)

我试过给你一个稍微不同的project.json 。 我已经逐字逐句地将其包含在内,但重要的区别是:

  • 我也想测试桌面运行时,所以我有两个框架目标
  • 我正在使用netcoreapp1.0而不是netstandard1.5
  • 我已经包含了Microsoft.NETCore.App依赖项,以及"type"="platform"
  • 看,没有运行时部分。 (可能是由于上述一些变化......)
{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

结果:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

呜。 (使用 net451 我得到 15646 的测试计数,这是我所期望的。)

接下来:在 Linux 机器上尝试同样的事情(如果没有修改,您的 project.json 可能无法正常工作,因为它没有提到 Linux,但理论上应该是我的;话虽如此,它是一台 Ubuntu 16.04 机器,所以它的dotnet CLI 有点结合在一起)。

唔。 在 14 分钟消耗 100% CPU 后,Linux 上的测试还没有完成。 需要更仔细地观察那里发生的事情。

@jskeet

我说还没有命令行参数支持,比如 --where 等,我说得对吗?

测试不佳,但我已经连接了--where和大多数常见的命令行参数。 我仍然有一个问题,nunit/dotnet-test-nunit#4 来检查它们是否都正确连接并且工作并添加任何可能丢失的。 到目前为止,我还没有测试过很多,但我已经使用了一些,将它们添加到dotnet命令的末尾。 我仍然需要弄清楚它是如何工作的。 例如, --debug命令行选项在dotnet-test-nunit解决方案中运行良好,但是当我从我的测试解决方案运行它时它抛出dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" 。 我也不知道如何将帮助命令行链接到我们的命令行以显示支持的内容。

同时,您可以查看https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs以了解我认为有哪些命令行选项支持:微笑:

啊,是的 - 看起来dotnet test没有与dotnet run相同的功能,用于将测试框架的参数与dotnet test本身的参数分开。 我一直在尝试

dotnet test -- --help

dotnet test -- --where=cat!=Slow

只是使用

dotnet test --where=cat!=Slow

工作正常。 将为此提交功能请求 - 能够完全明确是很好的。

单击测试并导航到代码现在固定在3.3.0.60-CI

还有两个高优先级的问题,然后我计划做一个 alpha 版本,届时我将关闭这个问题并跟踪新存储库中的所有内容。 这两个问题是;

  • [x] nunit/dotnet-test-nunit#22 向失败的测试添加消息和堆栈跟踪
  • [x] nunit/dotnet-test-nunit#12 TestContext.WriteLine 没有出现在 TestExplorer 测试摘要中

仅供参考,我今天在我的 Ubuntu 机器上再次运行了 Noda Time 测试,它们在大约 15 分钟后完成。 看起来它们在我的 Linux i5 上的运行速度比在我的 Win10 i7 上慢 5-6 倍。 不确定这与 CPU 有多少关系以及与 JIT 有多少关系 - 这绝对超出了 NUnit 的范围:)

@jskeet感谢更新,这是个好消息。 您是否需要如 nunit/dotnet-test-nunit#9 中所述的用于 Linux 测试的单声道绑定?

对于任何正在测试的人,最新的好 NuGet 包是3.3.0.69-CI ,请用它来测试。 现在没有我认为严重到足以阻止发布的突出问题。 如果本周没有报告,我可能会在本周晚些时候或下周初创建一个 alpha 版本。 一旦我这样做了,我将关闭这个问题,未来的讨论/问题可以在dotnet-test-nunit回购中继续。

立即测试或永远保持平静 :smile:

@rprouse :我还没有尝试在 Mono 上运行它 - 只有 Linux 上的 .NET Core。 这与上面的确切 project.json 工作得很好。

会给 69-CI 一个旋转...

我注意到这与控制台应用程序运行程序之间的一个区别是“dotnet test”版本似乎包括在整个持续时间内查找测试所花费的时间,而我曾经与 NUnitLite 一起使用的“dotnet run”命令没有. 在 Noda Time 中,这意味着如果我使用--where=cat==Foo (该类别中没有此类测试),“dotnet test”报告的持续时间为 14 秒,而“dotnet run”报告的持续时间为 0.01 秒 - 尽管它们都花费了大致相同的实际经过时间。

这是故意的吗? 我当然不介意这种行为,但在某处可能值得注意,以避免人们认为它实际上更慢。

@jskeet这是一个很好的观察,确实如此。 因为我们没有完整的 NUnit 引擎来运行测试,所以代码更简单,但我可能能够在第一个测试开始事件上启动时钟,而不是包装测试运行。 我将输入一个问题。

我已经在 GitHub 上发布了dotnet-test-nunit的 alpha 版本https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 ,因此您不再需要更改您的NuGet.config文件并使用 CI 版本。

现在我有了一个 alpha 版本,我将关闭这个问题。 请帮助我测试 alpha 并在https://github.com/nunit/dotnet-test-nunit/issues 中报告任何问题

我已经更新了自述文件中dotnet-test-nunit的文档。 我会及时更新。

https://github.com/nunit/dotnet-test-nunit

正如我之前提到的,如果您将"type": "platform"用于"Microsoft.NETCore.App"依赖项,则不需要指定运行时。 鉴于 xUnit 文档,我认为这是首选方法。

我目前有一个通过 Travis 运行的拉取请求 - 如果它变成绿色,Noda Time 将取决于这个,所以应该给它_some_用法。 干得漂亮,先生...

我刚刚注意到的一个缺点 - 这意味着我无法再轻松地在 Linux 上使用 Mono 进行测试。 我相信这不是 NUnit 的问题,它基本上是https://github.com/dotnet/cli/issues/3073的一种表现,但对于 NUnit。 我仍然希望它最终能得到修复; 目前我将在 Travis 中禁用我的单声道测试,有点不情愿。 ( dotnet test绝对是未来。)

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

UyttenhoveSimon picture UyttenhoveSimon  ·  3评论

xplicit picture xplicit  ·  5评论

DustinKingen picture DustinKingen  ·  4评论

ericnewton76 picture ericnewton76  ·  3评论

dgm90 picture dgm90  ·  5评论