xUnit fail of overload Testmethod on Visual Studio 2017 .NET Core

Visual Studio 2017 が出たぜー!というところで、さっそくBlackJumboDogもアップグレードしていったところ。

xUnitで謎のテストエラーが続発した・・・

System.InvalidOperatrionException
普通に考えたところで、メソッドの呼び出し方を間違えたとのことなのだが、型を動的にしているわけでもないので、あれま・・・とか思っていたところ。

よくよく見ていると、そのメソッドはオーバーロードしていた。

引数3つのTestメソッドと、引数2つのTestメソッドがいる状態
エラーメッセージは

メッセージ: System.InvalidOperationException : The test method expected 3 parameter values, but 2 parameter values were provided.

となっていて「引数が3つあるぞ、でも2つしかないぞ。」という困ったぞーという意味の例外。

なので・・・

オーバーロードをやめて名前を付けた。

というわけで、成功!

ひとまず回避策は見えたが、これが仕様なのか、不具合なのかは調べていない。。。

How to output log for xUnit

ひさしぶりに BlackJumboDogをいじっていて、
ずーっと気になっていたことがあったので、思わずやってしまった・・・。

xUnitでは、並列テストを前提とした場合標準出力に対する出力をキャプチャしない仕様になっている。そのため、出力させるためには、独自のOutputHelperが必要になる。
※ Capturing Output

これやるにあたって、今のSystem.Diagnostics.Traceを全て置き換える必要が
あった。

なぜかというと、System.Diagnostics.Traceは、コンテキストを持たずアプリケーション内で静的に動作してしまうため、並列で動いたときはどのテストの結果であるかを知ることができない。

そのため、ちゃんとやるなら、System.Diagnostics.Traceを全て独自のものに置き換える必要があったが、それにはかなりの修正量になるのがあってためらっていた。

しかしながら、実際のところテストがエラーになったとき、単純なものであればよいが、複雑なものであれば、どこがどうなっているかというのを追いかける必要がある。そのためには、ログも実行された結果がそのまま出てくれているのが良く、関係のないところの情報が出ていることは、逆に紛らわしい。そのため単独で動かしてその結果が出てくれるならいいがそうではなかったりもする。まぁその時点でテストとしての精度が低いという問題もあるのだけれども。

そこで、ログもすべて自分の実装でコンテキスト化してしまおうというのをやってみた。

・ログは出力先が不特定多数(ファイル、コンソール、xUnit、その他)
・ログは気軽に出すことをできるようにしておき、必要に応じて出力できないようにする
・ログはルートのコンテキストに紐づける

といったような考えで挑んでみたところ。

悪くはないが、そのための影響が大きくやはりやりすぎだったか!と思いつつ、前に進んでいることで何かやる気が出てきている今日だった。

change internal architecture for log. 

独自で実装しておくことは、チューニングしやすくなるので、悪くはない。

もし、今後xUnitを用いた開発をするのであれば、ログを出力する機構を
テストごとにコンテキスト化できるような仕組みをお勧めしたいなぁと思った。

 

.NET Core xUnit 出力のメモ

今日はちょっとしたメモ

.NET CoreでVisualStudio上のテストエクスプローラーから実行した場合、それまでのテストツールであれば、出力で、Traceなどの出力を確認することができました。
しかし、新しいxUnit v2.xでは標準でサポートされなくなりましたと。

https://xunit.github.io/docs/capturing-output.html
If you used xUnit.net 1.x, you may have previously been writing output to Console, Debug, or Trace. When xUnit.net v2 shipped with parallelization turned on by default, this output capture mechanism was no longer appropriate; it is impossible to know which of the many tests that could be running in parallel were responsible for writing to those shared resources. Users who are porting code from v1.x to v2.x should use one of the two new methods instead.

要するに、並列実行されるようになって、どこのテストの結果から出たTraceかわからなくなったと。これに責任持てるような手段がないとのこと。

代替として・・・

As you can see in the example above, the WriteLine function on ITestOutputHelper supports formatting arguments, just as you were used to with Console.

テストコードのあるクラスのコンストラクタに、ITestOutputHelperを引数として渡す。それにWriteLineメソッドを呼び出せば標準出力のように動いてくれると。といっても、Traceしたいので、なんとなく作りました。

https://github.com/darkcrash/bjd5/blob/CoreCLR/Bjd.Common.CoreCLR.Test/Logs/TestOutput.cs

使い方は、コンストラクタで、ITestOutputHelper を引数としてインスタンス化。DisposeでDisposeです。とはいえ、これはこれで、出力がただ出てくれるというだけで、根本的な解決ではないと認識しています。

これを作った経緯として、個別のテストでエラー箇所を特定するために出したかったというものです。なので、一括に動作してきれいな形で出てくれるが目的ではないのです。

こんな感じ

xUnit dnx

こんにちは!ツイッターネタです。

BlackJumboDogにテストコードいこうぜ!ということでこんな流れになってきました。タイミングとしても、ある程度動くようにコーディングが落ち着いてきた気がしてきています。(Linux側に少し課題は残っています。)

前記事の感触から、異なるフレームワークで動くようにするということはそれぞれに動作検証やら、テストやら必要になってきそうと思っています。そんなところで、CoreCLRとしてのテストコードがほしいと思う今日この頃でした。

http://xunit.github.io/docs/getting-started-dnx.html

ほぼ、リンク先の手順通りに進めます。

といいながら、最初は、project.jsonに対して、参照の追加

  • xunit
  • xunit.runner.dnx

次に、実行するための、commandを定義します。これはkestrelとかbjdと同じでエントリポイントを指し示すようなものといえば、わかりやすいかと思っています。つまり、このプロジェクトには、MAINはいらないという意味でもあります。

 

次に、唯一のクラスを作りました。サンプル通りのものです。

ビルドすると・・・。なんと!テストエクスプローラに出てくるではないですか!!

そして、そのまま調子にのって、すべて実行!

 

動いた・・・。特に何もいれてないんですが・・・。動いた・・・。不思議だ・・・。ふつう、拡張機能とか入れるもんだと思っていたんですが。

気になって、依存関係をのぞいてみました。何やら、TestHostっていうのがあるようですね。このあたりが提供している機能に乗っかっているだけなのかもしれません。

ちょっと、これは面白くなってきた・・・!ちなみに、なぜこうなるのかは、私自身わかっていません!

それでは!!