Tests unitaires en .Net avec des objets Endeca

Question

La plupart ou tous les objets de Endeca ont constructeurs internes. Je travaille sur un bon projet qui n'a pas une grande couverture de test autour de l'API Endeca, sont là de bonnes stratégies pour les tests unitaires les interactions avec Endeca?

Jusqu'à présent, le meilleur que nous avons est une sorte de modèle d'adaptation d'un pauvre homme:

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...
}

On peut alors se moquer de notre propre type, DimValue. Est-ce la meilleure façon de garder leur API comme testable peut être? Ou est-il une autre méthode qui est préférée à cela?

Answer 1

Si vous essayez de tester votre utilisation de l'API, alors je vous recommande l'approche que vous avez mentionné.

Il est un bon objectif de conception d'écrire votre application construite sur vos propres abstractions, pas quelqu'un d'autre. La couche d'adaptation vous donne une chance de traduire l'API dans un langage de domaine vos développeurs sont plus à l'aise et vous donne la liberté aux technologies de changement plus tard si le produit que vous utilisez est loin d'une certaine façon.

ReSharper avait une grande fonctionnalité pour créer des classes d'emballage. Créer une classe, ajouter un membre qui est le type que vous voulez envelopper .. puis déclencher Generate délégués refactoring. Choisissez « tout public » et là vous allez .. une classe enveloppé.

N'exposez le sous-ensemble de leurs fonctionnalités que vous utilisez réellement. Dans votre code d'emballage, de fournir des interfaces de sorte que vous pouvez simuler.

Si vous testez l'API Endeca comme une forme de suite de régression afin que vous puissiez plus facilement accepter de nouveaux libérés de leur API, alors je les tests juste écrire à un niveau plus « d'acceptation »; l'exercice de l'API qu'ils vous donnent. Mais encore une fois, ne tester que les moyens que vous utilisez réellement leur API.

Je ne l'approche ci-dessus, mais ...

Typemock vous permettra de cours simulacres sans interfaces, de sorte que peut permettre à une autre approche.

Hope this helps.

Answer 2

La plupart des classes sont Endeca en béton de sorte qu'il est difficile de faire des tests unitaires, dans notre dernier projet, nous nous devons définir une couche abstraite, exactement c'était une couche de façade entre notre propre code et API Endeca par exemple IEndecaQuery. Avec cette couche d'abstraction, nous pourrions faire un test rapide sans réel accès Endeca, vous savez ouvrir une connexion Endeca vous coûtera plusieurs secondes à chaque fois. Il a beaucoup de travail pour mettre en œuvre tous les objets faux Endeca nécessaires. Notre application est un site de commerce électronique et nous avons utilisé Endeca pour tous la liste des produits, des fonctions de recherche.