ENDECAオブジェクトを使用した.NETでのユニットテスト

Question

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をock笑することができます。これは、APIをできる限りテスト可能に保つための最良の方法ですか？または、これよりも好まれる別の方法はありますか？

Answer 1

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

他の誰かの抽象化ではなく、あなた自身の抽象化に基づいてあなたのアプリケーションを作成することは良いデザインの目標です。アダプターレイヤーは、APIを開発者がより快適であるドメイン言語に翻訳する機会を提供し、使用している製品が何らかの方法で不足している場合、テクノロジーを自由に変更することができます。

Resharperには、ラッパークラスを作成するための優れた機能がありました。クラスを作成し、ラップしたいタイプのメンバーを追加します。次に、Generate Delegatesリファクタリングをトリガーします。 「すべてのパブリック」を選んでください。

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

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

ただし、上記のアプローチを行います...

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

お役に立てれば。

Answer 2

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