非決定性と単体テストは、うまく両立しません。ただし、直面している唯一の非決定論は、ネイティブローダーから受け取るデータとその形式であると私は主張します。なんで?
一般的に機能することをテストします。ティッカーで価格の読み込みを開始し、読み込みが開始されることを確認します
これは、.NET コードで完全に制御する必要があります。ある種のジョブまたは手動のメソッド呼び出しのいずれかによって。非決定論はありません。
テストデータが流れています: いくつかのティッカーで価格の読み込みを開始し、ある程度の更新を受信したことを確認してください
繰り返しますが、.NET コードです。データのネイティブ ローダーに定期的にクエリを実行する別のジョブ、またはネイティブ ローダーからのイベントを監視して応答するジョブが必要です。
妥当な価格であることをテストする: ティッカーに価格の読み込みを開始し、予想される価格 (または少なくとも妥当な範囲の価格) を受け取っていることを確認します。
適正価格とは?0
からInt32.Max
?までの範囲 ネイティブ ローダーをテストしようとしないでください。それがどのように機能するかについて仮定を立て、それらの仮定に基づいてコードを構築します。もちろん、データ形式、範囲 (価格が負の値であってはならないなど) を検証することはできますが、それだけです。これにより、単体テストが必要な実際のコード(データをデータにマップするクラス(ドメイン オブジェクト - 単純な POCO -または)) が表示されます。ある種のビルダー/マッパー/コンバーター。StockQuotation
TickerData
ここで、2 つのテスト セットが必要です。1 つはビルダー/マッパー コード用で、後のコードが想定に沿って機能することを確認します。2 番目のセットは、従来のシステム/統合テストです。データのロードから実際のコンポーネントを使用した結果の構築までのプロセス全体です (ここでもティッカーが存在しなくなることは気にしないでください。
このような設定で何かが機能しなくなった場合、通常は次の 2 つのいずれかを意味します。
- ローダーのデータについて行った仮定が変更された (または何かを見落とした)
- ビルダー/マッパー/コンバーターが、有効な仮定に基づいて正しく実装されていません
この時点で、追跡の問題は簡単なはずです。誰にでもできるコードを書こうとしないでください。バグのあるコードは正常な状態です。それらを見つけて修正します。最初からエラー/例外を含まないコードを作成するよりも、エラー/例外に備える方がはるかに簡単です。言うまでもなく、サード パーティ コード (ネイティブ ローダー) のバグを実際に制御することはできません。