コンソールアプリを使用して、nunitliteを使用してdotnet run
(たとえば、このchessie commit )でnunitテストを実行できます。 そして動作します( dnxcore50
atmを忘れて、 netstandard
でなければなりません)
ただし、.NET CLI(https://github.com/dotnet/cli)でテストを実行する場合、コマンドはdotnet test
dotnet test
は、discover / debug / etcについてides(ref dotnet / cli#1376)からサポートを提供する必要があるものです。
これが現在の方法であり、dnxは非推奨になり(#927は閉じる必要があります)、aspnetとdnxは.NETCLIに移行します。
dotnet test
必要な新しいライブラリdotnet-test-nunit
dotnet test
dotnet-test-xunit
と同じ(https://github.com/xunit/coreclr.xunit/pull/1を参照)
xunitテストプロジェクト(https://github.com/dotnet/cli内のテストを参照)の例project.json
は次のとおりです。
{
"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
(ref source )によって読み取られ、 dotnet-test-{testRunner}
を使用します
/ cc @piotrpMSFT @livarcoccは、.NET CLIとdotnet-test、dotnet-test-xunitで動作するため、より多くの情報が得られるため、情報を提供します:smile:
私はそれを手伝うことができます、それがあなたにとって大丈夫であり、 @ piotrpMSFTが行くと言うなら(それは私が思うに安定した
.NET Coreが少し落ち着くのを待ってから、#927に進みました。そのため、新しいタイトルと情報で更新されていません。 // buildで発表される可能性のあるアナウンスを待ってから先に進むことを計画していましたが、何か助けをいただければ幸いです。 私の計画は、.NET Core、UWP、Xamarinなどの3.4リリースで、より多くのプラットフォームのより完全なサポートの提供を開始することです。
あなたはここによく書かれた要約を提供したので、私は#927を閉じて、今後の追跡のためにこの問題を使用します。 この問題についてサポートが必要な場合は、調整できますが、サポートをお待ちしております。
このプロセスの最初のステップは、NUnitLiteや現在のXamarinランナーなどの特定のバージョンのNUnitフレームワークに厳密にバインドされることなく、テストをロードして実行できるPCLドライバー/エージェントを作成することでした。 まだ初期段階ですが、進行中の作業はnunit.portable.agentプロジェクトにあります。
@piotrpMSFTまたは@livarcoccが提供できるヘルプやアドバイスもありがたいです:smile:
@rprouse CLIにバグがあり、
これはそれを追跡するバグです: https :
これはどうですか? これを使いたいのですが、dotnetcliエコシステムは安定しているようです。
少し進歩していますが、RC2が落ちるまでやりすぎたくありません。 私は変化に遅れずについていくことにうんざりしています:smile:
.NET Core RC2がリリースされ、新しい情報が利用可能になりました。 参考のためのリンク。
ここで何か手伝ってもらえますか? これは、StackExchange.Redisなどの一部のポートを完了するためのブロッカーです。
@NickCraver私は間違いなくいくつかの助けを使うことができました、その通信プロトコルの最初の読み取りは物事をひどく明確にしませんでした:smile:
最初のステップは、これにどのように取り組むかを決定することです。 現在、.NET Coreを対象としたポータブルビルドがありますが、制限があります。 フレームワークのコアビルドを作成することを検討していますが、必要かどうかはわかりません。
次に、 dotnet
コマンドのテスト拡張機能を作成するために必要なものを確認する必要があります。
最後に、nunit3-consoleが.NET Coreユニットテストを実行できるように、nunitエンジンを起動してコアnunit-agentと通信できるようにしたいと思います。 私はこれに取り組んできましたが、まだやるべきことがたくさんあります。
どのようにお手伝いしますか?
@rprouseクロスプラットフォームで使用するには、
正直なところ、残りの作業量を考えると、これにどれだけの時間をかけることができるのか、他の場所に投資するのかはわかりません。 今のところ、ライブラリとアプリの構築を待っている多くの川下の人々のために、ライブラリを戸外に出す必要があります。 私はこれを言うのは嫌ですが、ここでの遅れと今日利用可能なものを考えると、すべてをxUnitに移植し終える必要があると思います。そうしないと、何百から何千もの開発者がここでブロックされたリリースのチェーンを待っています。
安定して時間が許せば、これを再検討しますが、(間違っている場合は訂正してください)現時点では、私が前に残っている(あなたの投稿による)数週間の作業について話しているところです。 dこれを使用して、ライブラリポートの出荷準備が整ったことを期待して実行できます。 著者の義務の観点から、私は最初に私の上の人々のブロックを解除し、次に私ができる限り上流を助ける必要があります。
@NickCraverは、xUnitへの移植に労力を費やすよりも、.NETCoreテストを実行するためのコマンドラインNUnitLiteランナーを作成する方が簡単な場合があります。 これは完璧な解決策ではありませんが、おそらく最小限の作業です。 少し時代遅れですが、 NUnit3を使用した.NETCoreのテストでその方法についてブログを書きました。
私はいくつかの個人的なプロジェクトのためにそれをそのようにやっていて、それは機能的です。
適切なdotnet-test-nunitビルドを作成するお手伝いをさせていただきます。 多くの人が恩恵を受けると確信しています。 プロトコルで定義されているコントラクトの多くは、ヘルパーライブラリにすでに実装されています。 xplat nunitランナーが機能している場合、これはほとんど作業になりません。
これを2つのフェーズに分割するのに役立ちますか?一種の「迅速で汚い、粗雑なハックがあるかもしれませんが、少なくとも何かをそこに出しましょう」リリースと、後でより本格的な統合です。
(たとえば、netstandard1.3のTFMを使用してテストを構築しようとすると、Noda Timeのブロックを解除するのに大いに役立ちます。)
@jskeetと@NickCraverは、@ rprouseが提案したように、NUnitliteの「ハック」を介して今日NUnitを使用できます。私はNpgsqlに対してこれをしばらく行っていますが、うまく機能します。 これは完璧な解決策ではありませんが、間違いなくブロックを解除する必要があります。
@roji :それはdnxcore50
(私はしばらくの間Noda Timeで使用しています)-しかしnetstandard1.3
を使用すると、NUnitとNUnitLiteへの依存関係は無効になります。
@jskeet私のテストプロジェクトはnetcoreapp1.0をターゲットにしており、Nunit + NUnitLite3.2.1に依存しています。 私は"imports" : [ "dotnet54" ]
を持っていて、それは魅力のように機能します...
@roji :ありがとう...指が交差した...
@roji :実際にテストを実行するのにまだ問題があります-フォローする例として、テストプロジェクトでこれを実行している場所にリンクできますか?
@jskeet確かに、ここに行きます: https :
@jskeetインポートも機能するはずです。 RC2はいくつかの変更点があるので、RC2を念頭に置いてNUnit 3でテストする方法についてのブログ投稿を書き直し、コードをGitHubに投稿します。 完了したら、できれば今朝(EST)にリンクをここに追加します。
@piotrpMSFT時間を節約して、 dotnet-test-nunit
を作成するためのヘルパーライブラリを教えていただけますか? 検索はできますが、現時点ではいくつかのことを追いかけているので、助けていただければ幸いです。 あなたも忙しいと思いますので、手元にない方は時間をかけないでください。見つけます。
興味のある人のために、更新されたブログ投稿Testing .NET Core RC2 Using NUnit3を投稿しました。
@jskeetには、project.jsonにimportsステートメントが必要です。 これは、新しい.NET Coreテンプレートにデフォルトで追加されますが、アップグレード時に追加する必要があります。
コンソールランナーのproject.jsonの場合。
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
またはアセンブリ内。
"frameworks": {
"netstandard1.5": {
"imports": "dnxcore50"
}
RC2にアップグレードするとき、私のパスに古いDNXのものがあることも私を噛みました。 チェックするもの。
@rprouse :ありがとう; これでビルドできるようになり、テストはWindowsで実行されます。 Linuxでは、「オブジェクト参照がオブジェクトのインスタンスに設定されていません」と表示されます。 dotnet run
に関するメッセージ。これについては、さらに調査する必要があります。 最小限のサンプルを試して、同じ問題があるかどうかを確認します...
@oschwald :
@jskeetいくつかの原因がありますが、これはあなたのものですか? https://github.com/dotnet/cli/issues/3075
@NickCraver :いいえ-ドットネットの復元を正常に実行しました。
私の場合、別のプロジェクトに依存せずに機能するproject.jsonファイルがありますが、失敗します。 完全な再現を考え出すのにもう少し時間をかける必要があります。
うーん...そして今それは働いています。 @NickCraverが報告したのと同じ問題であり、それを修正するために間違ったプロジェクトをdotnet restore
だけ行っていた可能性があります。 とにかく、私は今LinuxでNoda Timeテストを実行しているので、イェーイ:)みんなありがとう。
@piotrpMSFTポインターのリクエストについて、必要なものがすべて見つかり、作業を開始しました。
nunit / dotnet-test-nunit#1にdotnet-test-nunit
ランナーの初期PRを追加しました
テストを調査して実行しますが、それでもいくつかの作業、クリーンアップ、およびテストが必要です。 誰かがそれを試してみたい場合は、ビルドアーティファクトのNuGetフィードにアクセスしやすくします。
Visual StudioによってロードされたときにNuGetパッケージをデバッグする方法について誰かがアイデアを持っている場合は、いくつかのヘルプを使用できます。 これまでのところ、Visual Studioで実行されていませんが、セットアップの問題である可能性があります。
@rprouse :もしそれが役に立ったら、野田タイムがどのようにそれに対処するかを見てうれしいです。 特にチェックしてほしいことがあれば教えてください。 あなたのすべての仕事に感謝します!
プライムタイムの準備はまだできていませんが、コンソールとVisualStudioでNUnit.NETCoreテストを実行しています。 アルファ版をリリースする前に解決すべき問題がまだいくつかありますが、ハードワークが完了し、詳細に至るまで、今でははるかに近づいています。
いくつかの問題を修正した後、CIビルドでテストする方法の詳細を投稿します。 人々がタイヤを蹴って問題を見つけるのを手伝ってくれたら幸いです。
これがスクリーンショットです。
@rprouse :CIビルドの進捗状況はありますか? タイヤを蹴るのは間違いなく熱心です。 Noda Timeは_合理的な_数のNUnit機能を使用しているので、とにかく良いスタートになるはずです。 VSで再びテストを実行できることを本当に楽しみにしています。 (NCrunchとCodeRush for Roslynも、リリースされたらサポートを開始することを願っています...)
@jskeetや、アルファ版をリリースする前にテストを手伝ってくれることに興味がある人たちのために、 dotnet-test-nunit
ブランチのデモリポジトリをdotnet-test-nunit
ランナーを使用しました。
nunit / dotnet-test-nunitリポジトリで問題を報告してください。
高レベルの指示は次のとおりです。
更新: dotnet-test-nunit
がNuGetでアルファ版として利用できるようになりました。 Include prereleases
。 nuget.config
ファイルを更新する必要はもうありません。
dotnet-test-nunit
はまだ開発中であるため、NUnit CI NuGetフィードからNuGetパッケージをダウンロードするには、ソリューションにNuGet.Config
ファイルを追加する必要があります。
テストプロジェクトのproject.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
依存関係がテスト中のプロジェクトであることに注意してください。
テストアダプタとしてNUnit3を指定するために、 "testRunner": "nunit"
を追加しました。 また、テストアダプタとNUnitの両方を解決するためにインポートに追加する必要がありました。 最後に、 runtimes
を追加する必要がありました。 なぜそうする必要があるのか誰かが説明できるなら、私に知らせてください。
これで、Visual Studio Test Explorerを使用するか、コマンドラインから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
修正されました。 上記の手順を修正して更新します。 もう1つの未解決の問題は、現在、ランナーにテストの行番号を提供していないため、VisualStudioテストエクスプローラーでテストをクリックしてもコードに移動できないことです。
--where
などのコマンドライン引数のサポートはまだないと言っているのは正しいですか? (私はそれが初期のことであることを完全に理解しています-これが私ができるべきことであるかどうかをチェックしようとしているだけです。)
少し違うproject.json
を試してみました。 以下に逐語的に含めましたが、重要な違いは次のとおりです。
netcoreapp1.0
代わりにnetstandard1.5
"type"="platform"
とともにMicrosoft.NETCore.App
依存関係を含めました{
"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はややくっついています)。
うーん。 Linuxでのテストは、100%CPUを14分間消費した後も終了していませんでした。 そこで何が起こっているのかをもっと詳しく調べる必要があります。
@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 test
自体への引数から分離するためのdotnet run
と同じ機能がないようです。 私はしようとしていた
dotnet test -- --help
と
dotnet test -- --where=cat!=Slow
使用するだけ
dotnet test --where=cat!=Slow
正常に動作します。 そのための機能リクエストを提出します-完全に明確にできるのは素晴らしいことです。
テストをクリックしてコードに移動することは、 3.3.0.60-CI
修正されました。
まだ2つの優先度の高い問題があります。その後、アルファリリースを実行することを計画しています。その時点で、この問題を閉じて、新しいリポジトリ内のすべてを追跡します。 2つの問題は次のとおりです。
参考までに、今日も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
です。それを使ってテストしてください。 現在、リリースをブロックするほど深刻だと思う未解決の問題はありません。 今週何も報告されない場合は、今週後半または来週初めにアルファリリースを作成する可能性があります。 それができたら、この問題を閉じます。今後のディスカッション/問題は、 dotnet-test-nunit
リポジトリで続行できます。
今すぐテストするか、永遠にあなたの平和を保ちましょう:smile:
@rprouse :Monoで実行しようとしたことはありません
69-CIに旋風を巻き起こします...
これとコンソールアプリランナーの違いの1つは、「dotnet test」バージョンには、全体の期間でテストの検索に費やされた時間が含まれているように見えるのに対し、NUnitLiteで使用していた「dotnetrun」コマンドには含まれていないことです。 。 野田時間では、これは、 --where=cat==Foo
実行した場合(そのカテゴリにそのようなテストはありません)、「dotnet test」は14秒の期間を報告しますが、「dotnetrun」は0.01秒の期間を報告します-にもかかわらずどちらも実際の経過時間はほぼ同じです。
これは意図的なものですか? 私は確かにその振る舞いを気にしませんが、実際には遅いと人々が思わないように、どこかで注目する価値があるかもしれません。
@jskeetは良い観察です、それは確かに事実です。 テストを実行するための完全なNUnitエンジンがないため、コードはより単純ですが、テスト実行をラップするのではなく、最初のテスト開始イベントでクロックを開始できる可能性があります。 問題を入力します。
https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1のGitHubでdotnet-test-nunit
アルファ版をリリースしたので、変更する必要はありません。 NuGet.config
ファイルとCIリリースを使用します。
アルファ版がリリースされたので、この問題を解決します。 アルファ版をテストし、 https://github.com/nunit/dotnet-test-nunit/issuesで問題を報告するのを手伝って
readmeのドキュメントをdotnet-test-nunit
更新しました。 私はそれを最新の状態に保ちます。
前に述べたように、 "Microsoft.NETCore.App"
依存関係に"type": "platform"
を使用する場合は、ランタイムを指定する必要はありません。 xUnitのドキュメントを考えると、これが推奨されるアプローチだと思います。
現在、Travisを介してプルリクエストを実行しています。これが緑色になった場合、Noda Timeはこれに依存するため、ある程度の使用法が得られるはずです。 よくできました、サー...
今気付いた欠点の1つは、Linux上のMonoで簡単にテストできなくなったことを意味します。 これはNUnitの問題ではなく、基本的にhttps://github.com/dotnet/cli/issues/3073の症状ですが、NUnitの問題だと思います。 私はまだそれが最終的に修正されるかもしれないことを望んでいます。 とりあえず、少し気が進まないうちに、Travisでのモノラルテストを無効にします。 ( dotnet test
は間違いなく未来です。)
最も参考になるコメント
プライムタイムの準備はまだできていませんが、コンソールとVisualStudioでNUnit.NETCoreテストを実行しています。 アルファ版をリリースする前に解決すべき問題がまだいくつかありますが、ハードワークが完了し、詳細に至るまで、今でははるかに近づいています。
いくつかの問題を修正した後、CIビルドでテストする方法の詳細を投稿します。 人々がタイヤを蹴って問題を見つけるのを手伝ってくれたら幸いです。
これがスクリーンショットです。