Тестирование модуля в .Net с объектами Endeca

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. Является ли это лучшим способом сохранить свой API как проверенный, как может быть? Или есть другой метод, который предпочтительнее этого?

Answer 1

Если вы пытаетесь проверить использование вами API, я бы рекомендовал вам упомянутый вами подход.

Это хорошая цель дизайна, чтобы написать свое приложение, основанное на ваших собственных абстракциях, а не на чужом. Адаптерный слой дает вам возможность перевести API на язык домена, которым ваши разработчики более удобны, и дает вам свободу в дальнейшем менять технологии, если используемый вами продукт каким-то образом не подходит.

У Resharper была отличная возможность для создания классов-оболочек. Создайте класс, добавьте член, который является типом, который вы хотите обернуть, затем активируйте рефакторинг делегатов для создания делегатов. Выберите «все публичные», и вы идете ... один завернутый класс.

Только выведите подмножество их функциональных возможностей, которые вы фактически используете. В вашем оберточном коде укажите интерфейсы, чтобы вы могли высмеивать.

Если вы тестируете API Endeca как часть формы регрессии, чтобы вы могли легче принять новые выпущенные из их API, то я бы просто написал тесты на более «приемном» уровне; используя API, который они вам дают. Но опять же, проверьте только то, как вы на самом деле используете свой API.

Я бы выше подход, однако ...

TypeMock позволит вам имитировали классы без интерфейсов, так что может позволить другой подход.

Надеюсь, это поможет.

Answer 2

Большинство классов Endeca являются бетонными, поэтому трудно выполнить единичное тестирование. В нашем последнем проекте мы должны определить абстрактный слой, именно это был фасадный слой между нашим собственным кодом и API Endeca, например. IEndecaQuery. С этим уровнем абстракции мы могли бы быстро выполнить тест без какого-либо реального доступа Endeca, вы знаете, что открытие соединения Endeca будет стоить вам несколько секунд каждый раз. Было много работы по реализации всех необходимых поддельных объектов Endeca. Наше приложение было сайтом электронной коммерции, и мы использовали Endeca для всех списков продуктов, функций поиска.