Как лучше всего выполнить рефакторинг кода, который состоит из других частных объектов, созданных в конструкторе - PullRequest
Новая
       5

Как лучше всего выполнить рефакторинг кода, который состоит из других частных объектов, созданных в конструкторе

0 голосов
/ 10 июня 2010

У меня есть следующий код, который был написан без тестов, но на самом деле довольно хорошо спроектирован и плохо связан.CachedBindingListView создает ряд объектов, а именно провайдер страниц и кэш.Как следует. 

    /// <summary>
    /// Inner data cache
    /// </summary>
    private Cache<T> InnerCache { get; set; }

    /// <summary>
    /// Page provider
    /// </summary>
    private PageProvider<T> PageProvider { get; set; }

    /// <summary>
    /// the Request object that is built with a filter, sort, no of pages etc.
    /// </summary>
    private BindingListRequest<T> BindingListRequest { get; set; }

    #endregion

    #region Constructor

    /// <summary>
    /// New object
    /// </summary>
    /// <param name="bindingListRequest">Request for a particular set of Business Objects</param>
    public CachedBindingListView(BindingListRequest<T> bindingListRequest)
    {
        BindingListRequest = bindingListRequest;
        PageProvider = new PageProvider<T>(BindingListRequest);
        InnerCache = new Cache<T>(PageProvider);
    }

Я написал тесты для BindingListRequest, PageProvider и InnerCache.но теперь хочу начать писать тесты для CachedBindingList.В настоящее время конструктор принимает BindingListRequest и на его основе создает провайдер страниц и внутренний кеш.

Для целей тестирования я хочу иметь возможность предоставить в TestDouble для PageProvider и Cache.

Что такоеЛучшие способы сделать это.Я рассмотрел следующие варианты.

1) Добавьте PageProvider и InnerCache в конструктор и введите соответствующий тип при необходимости.

2) Используйте инфраструктуру DI для разрешения PageProvider и Cacheвнутри конструктора CachedBindingListView.Это потребует либо внедрения контейнера DI в конструктор CachedBindingListView, либо его глобализации.

3) Создание фабрики, которая создает PageProvider и Cache и, возможно, даже CachedBindingListView, и использование этой фабрики для создания PageProvider и InnerCache вКонструктор CachedBingingListView.Это снова потребует либо сделать фабрику глобальной, либо внедрить ее в конструктор CachedBingingListView.

4) Сделать открытыми свойства PageProvider и InnerCache и использовать инфраструктуру DI для создания CachedBindingListView и внедрения свойств PageProvider и InnerCache через свойствоинъекции.Таким образом, позволяя мне переопределить Cache и PageProvider, внедряемые во время тестирования.

Я могу видеть, как все это может работать, но все они кажутся немного громоздкими и вынужденными.Какие мнения там.Какой совет есть у кого-нибудь о наилучшем способе сделать это?

спасибо GD

1 Ответ

1 голос
/ 10 июня 2010

Если вы просто хотите иметь возможность протестировать его - один из вариантов - создать защищенный конструктор со всеми тремя введенными свойствами. Затем в своем тесте создайте FakeCachedBindingListView, который наследуется от CachedBindingListView, и вставьте необходимые заглушки, макеты (выберите яд).

В любом случае, я бы пошел с этим.

...