2

Endecaのオブジェクトのほとんどまたはすべてには、内部コンストラクタがあります。私は、Endeca API に関する優れたテスト カバレッジが不足している優れたプロジェクトに取り組んでいます。Endeca との相互作用を単体テストするための適切な戦略はありますか?

これまでのところ、私たちが持っている最善の方法は、貧乏人のアダプター パターンのようなものです。

public class DimValue : IDimValue
{
    public DimValue(Dimension dim, DimVal dimValue)
    {
        Dimension = dim;
        Value = dimValue;
    }

    public virtual bool IsNavigable()
    {
        return Value.IsNavigable();
    }

    public virtual long Id()
    {
        return Value.Id;
    }

    // and so on...
}

次に、独自の型 DimValue をモックできます。これは、API を可能な限りテスト可能に保つための最良の方法ですか? または、これよりも優先される別の方法はありますか?

4

2 に答える 2

1

API の使用方法をテストしようとしている場合は、あなたが言及したアプローチをお勧めします。

他の誰かの抽象化ではなく、独自の抽象化に基づいてアプリケーションを作成することは、優れた設計目標です。アダプター レイヤーにより、API を開発者がより使い慣れたドメイン言語に変換する機会が得られ、使用している製品が何らかの形で不足している場合に後で技術を変更する自由が得られます。

Resharper には、ラッパー クラスを作成するための優れた機能がありました。クラスを作成し、ラップしたいタイプのメンバーを追加してから、デリゲートの生成リファクタリングをトリガーします。「すべて公開」を選択すると、ラップされたクラスが 1 つ作成されます。

実際に使用している機能のサブセットのみを公開してください。ラッピング コードで、モックできるようにインターフェイスを提供します。

Endeca の API を何らかの形式の回帰スイートとしてテストして、新しいリリースの API をより簡単に受け入れられるようにする場合は、より「受け入れ」レベルでテストを記述します。彼らがあなたに与えるAPIを行使します。ただし、実際に API を使用している方法のみをテストしてください。

私は上記のアプローチを行いますが、...

TypeMock を使用すると、インターフェイスなしでクラスをモックできるため、別のアプローチが可能になる場合があります。

お役に立てれば。

于 2010-10-07T21:33:30.353 に答える
0

ほとんどのEndecaクラスは具体的であるため、単体テストを行うことは困難です。前回のプロジェクトでは、抽象レイヤーを定義する必要があります。これは、独自のコードとEndeca API（IEndecaQueryなど）の間のファサードレイヤーでした。その抽象化レイヤーを使用すると、実際のEndecaアクセスがなくても迅速にテストを実行できます。Endeca接続を開くには、毎回数秒かかることがわかります。必要なすべてのEndeca偽のオブジェクトを実装するのは大変な作業でした。私たちのアプリケーションはeコマースサイトであり、すべての製品リスト、検索機能にEndecaを利用しました。

于 2010-10-08T04:33:12.510 に答える