モックを使用した反復コードのテスト - それは理にかなっていますか？

Question

モックを使用してアルゴリズムをテストしたい。アルゴリズム - 現在の実装では、複数のパスとset（）sとget（）s値でコンテナクラスを反復します。テストの目的は、コンテナに保存された最終結果を確認することです。最終的な値は、パスの間に読み取りおよび書き込まれた値に依存します。たとえば、任意の要素の値は、アルゴリズムが終了するまで複数回変更される場合があり、ほとんどの場合、反復nの結果としての値は、反復N-1後の値に依存します。

私はモックのアイデアが好きで、上記のシナリオでそれらを使用したいと思っています。これにより、計算が終了したときだけでなく、アルゴリズムの誤った動作を検証できるからです。ただし、現在の実装に近いモックに対する期待を実際に結びつけなければならないので、これが実際に良いアイデアであるかどうかはわかりません（例：「要素n）とxを返す、次に設定します（要素n、値x+1）、別のget（n）、およびx+1を返す、次にset（n、x+2）などを期待します。 "）。

中間値が予想通りであることを確認することを可能にしますが、そのような期待はテストの目的と矛盾すると思います（アルゴリズムが正しい最終値を計算することを確認します）。最終値。

今私の質問：私は何かが足りませんか？それにもかかわらず、このシナリオでモックを使用する良い方法はありますか？それとも、ここでそれらを使用することは意味がありませんか？他の人はこの問題にどのように対処しますか？

最終的な発言：C ++コードのテストとGooglemockの使用について話しているのですが、それがあなたの答えに何らかの違いをもたらす場合です。

PS：ここでGoogleと記事をチェックしました（特に 反復的な動作をock笑します - しかし、返品値を増やすという問題に取り組むだけですが、私は自分の問題に近いものを見つけませんでした。

Answer 1

コンテナが何らかの方法で遅い場合、または副作用がある場合、それを邪魔することなくその値を読むことができないことを意味する場合は、模擬を使用する必要があります。

それ以外の場合、模擬の使用は時間の無駄です。モックされたバージョンを使用しますか std::vector？私はしません。それはばかげているでしょう。

ユニットテストでは、さまざまなパブリックパラメーターを使用してアルゴリズムの内部状態をすべてテストできない場合、それらの状態は実際には重要ではありません。彼らは決して実際に使用することはできません。したがって、入力パラメーターのセットごとにアルゴリズムから正しい最終回答を得る限り、私は物事がうまく機能していると思います。

Answer 2

アルゴリズムの最終出力のユニットテストを作成します。プログラムの他の部分が利用するものであるため、自動化されたテストが期待される結果を検証する必要があります。

アルゴリズムコード内の個々の手順をテストする限り、これは自動テストではなく、デバッガーで介入するための仕事です。アルゴリズムの内部作業を行うことは1回限りのものである必要があり、一度それを手に入れると、その中の個々のステップをテストし続ける必要はありません。

Answer 3

ユニットテストは、アルゴリズムを構成する小さな部分でより適用できます。

そうは言っても、ユニットテストツールは、そのようにアルゴリズムを開発するのに非常に役立ちます。彼らはまったく使うのはまったく悪くありません。彼らがもう有効でなければ、彼らを抱きしめないでください。通常、統合テストで各反復をテストすることはなく、結果をテストするだけです。ただし、そのようにアルゴリズムを開発することが役立つ場合は、それを求めてください。

あなたは模擬について正しいです、あなたは本当にあまりテストしていません。ただし、いくつかの入力を制御する場合は便利です。多くの場合、私は私が制御できないブラックボックスがあるとき、徹底的な方法で私の入力を徹底的な方法で許可します。ただし、この種のテストは長すぎます。私は通常、それらがソースコントロールに入ったときにそれらを完全にまたは部分的にコメントします。