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

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


unit-testing .net mocking endeca
person Chris Missal    schedule 06.10.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

Однако я бы сделал описанный выше подход...

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

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

person Nigel Thorne    schedule 07.10.2010

arrow_upward
0
arrow_downward

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

person Tien Do    schedule 08.10.2010