ユニットテストでFakeItEasyを使用すると、非常に奇妙な問題が発生します...
モックが呼び出されたかどうかを表明し、メソッドのパラメーターの1つに次のような制約を指定します。
A.CallTo(() => fakeStorageClient.StoreAsync("commands", A<CommandEnvelope<FakeCommand>>.Ignored, false)).MustHaveHappened(Repeated.Exactly.Once);
問題は、このアサーションが時々失敗することです。通常、すべてのテストを1回の実行（「すべて実行」）で実行すると失敗することに気付きましたが、この特定のテストをFact単独で実行した場合は失敗しません。お気づきのように、この方法はasync非同期関連の問題について考えていたのですが、すべての呼び出しは適切にawait編集されています。
アサーションの失敗の詳細を見ると、ログは次のとおりです。
Assertion failed for the following call:
Backend.Data.MessageStorage.IMessageStorageClient.StoreAsync("commands", <NULL>, False)
Expected to find it exactly once but found it #0 times among the calls:
1: Backend.Data.MessageStorage.IMessageStorageClient.StoreAsync(
tableName: "commandStream",
entity: Backend.Domain.Commands.CommandEnvelope`1[Backend.Domain.Tests.FakeCommand],
streamMode: True)
2: Backend.Data.MessageStorage.IMessageStorageClient.StoreAsync(
tableName: "commands",
entity: Backend.Domain.Commands.CommandEnvelope`1[Backend.Domain.Tests.FakeCommand],
streamMode: False)
ご覧のとおり、予期された呼び出しは発生しましたが（ケース＃2）、何らかの理由で、FakeItEasyは2番目のパラメーターとしてNULLを使用した呼び出しを予期していました。
FakeItEasyがA<CommandEnvelope<FakeCommand>>.Ignored制約をNULLに評価する理由、さらに、それがたまにしか評価されない理由を誰かが理解するのを手伝ってくれることを願っています...
この問題は、最新のFakeItEasy2.0.0リリース候補で修正された問題476の兆候であることが判明しました。そのバージョンにアップグレードすると、シングルスレッドでテストを実行すると予想されるように、修正されました。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加