0

したがって、私は C# と .NET での単体テストとモックの両方についてかなりの初心者です。私はそれぞれ xUnit.net と Rhino Mocks を使用しています。私は改宗者であり、純粋な TDD ではなく、動作仕様の作成に専念していると思います。ああ、セマンティクス。本質的に、自動化されたセーフティネットが上記で機能することを望みます。

しかし、ある考えが私を襲った。私はインターフェイスに対してプログラミングを行いますが、依存関係を切り離すという利点はそこにあります。売却。ただし、私の動作検証スイート (別名ユニット テスト ;-)) では、一度に 1 つのインターフェイスの動作をアサートしています。のように、一度に 1 つのインターフェースの実装で、その依存関係がすべてモックアウトされ、期待値が設定されます。

このアプローチは、クラスが連携する依存関係に対して適切に動作することを検証し、さらに連携する依存関係のそれぞれに依存して同じ品質契約に署名することを検証する場合、私たちは成功しているようです。十分に合理的に思えます。

しかし、考えに戻ります。一緒に配線された具体的な実装のユニットに対してテストフィクスチャがアサートし、モックされた依存関係に対してその内部動作をテストしている半統合テストに価値はありますか? 読み直したところ、おそらくもっとうまく表現できたはずだと思います。明らかに、ある程度の「まあ、それがあなたにとって価値があるなら、それを続けてください」と思うでしょう-しかし、他の誰かがそれを行うことを考え、コストを上回る利益を得ましたか?

4

2 に答える 2

0

あなたの質問は何年も議論されてきましたが、「単位とは」と言い換えることもできますか?

各クラスを個別にテストする必要があるという単体テストの法則はありません。ただし、保守可能にするためには、テストする動作が変更された場合にのみテストを変更する必要があります。このように考えると、近い協力者の具体的なバージョンと、より遠い協力者の偽物を使用することが合理的であることがよくあります。

私が何らかの偽物を絶対に使用する場所の 1 つは、Michael Feather のユニット テストのルールに従うことです。

于 2008-11-15T18:04:59.180 に答える
0

完全に単体テスト可能な内部クラスをリンクするだけの統合テストには価値がありません。

統合テストの価値は、プラットフォームまたは外部インターフェースに触れるところにあるように私には思えます。つまり、単体テストできないコントラクトです。

于 2009-07-15T07:15:59.550 に答える