私は基本的にパイプラインのクラスを持っています。メッセージを処理し、バッチで削除します。これを行うには、ProcessMessage()
メソッドはメッセージを直接削除しません。私書箱Observable<IMessage>()
に追加します。私はそれから、観測可能なものを監視し、メッセージを大量に削除する別の公開方法を持っています。以下のようなコードになりプライベートプロパティを使用するパブリックメソッドの単体テストをテストするにはどうすればよいですか?
:
public void CreateDeletionObservable(int interval = 30, int messageCount = 10)
{
this.processedMessages.Buffer(TimeSpan.FromSeconds(interval), messageCount).Subscribe(observer =>
{
client.Value.DeleteMessages(observer.ToList());
});
}
問題は、私のユニットテストがprocessedMessages
の値がないということです。プライベートなので、私はmoq'dの値を提供することはできません。私は、どの値がprocessedMessagesにあるかをテストする必要はありません。私は、そのメソッドの動作をテストするために、それらが存在する必要があります。具体的には、例外がスローされた場合(そのロジックはまだコードにない)、私のobservableが実行を継続することをテストする必要があります。私はそれを見るので、私はいくつかのオプションがあります:
1)1人のエントリーポイントといくつかの終了(成功、エラー、再試行など)を持つ単一のモンスター観察可能なチェーンを使用するように私のクラスをリファクタリングします。このはで、パブリックメソッド間でコレクションを渡すためにプライベートプロパティを使用しないようにします。しかし、その連鎖は、はるかに少ないユニットテストを解析することは非常に困難です。私は自分のコードを読みにくくてテスト可能にすることは実行可能な選択だとは思わない。
2)は、メッセージのテストリストを受け入れるように、私のCreateDeletionObservable
方法に変更します
public void CreateDeletionObservable(int interval = 30, int messageCount = 10, IObservable<IMessage> processedMessages = null)
私が使用するメソッドのスタブデータを供給できるようになるが、それは恐ろしいコードのにおいです。これのバリエーションは、Observableをコンストラクタレベルに挿入することですが、それは良くありません。おそらく悪い。
3)processedMessages
を公開します。
4)この機能はテストしないでください。
私はこれらのオプションが嫌いですが、私は2に向かって傾いています。テスト目的のためのリストを注入する。私はここで行方不明のオプションはありますか?
私はMoqが私有財産を模倣できると考えました。私は間違っているのですか? –
@CodeswithHammerそれは理想的でしょう。おそらく私はそこにいくつかの機能が欠けているでしょうか?私はAPIドキュメントを掘り下げます。 – Necoras
'processedMessages'をコンストラクタ注入する際の下手なことは何ですか? – Shlomo