Глядя на рефакторинг Appsettings и HttpContext для модульного теста и moq - PullRequest
Новая
       13

Глядя на рефакторинг Appsettings и HttpContext для модульного теста и moq

1 голос
/ 29 ноября 2011

Я рассмотрел множество примеров, но в этом случае я хотел бы получить свежую точку зрения на рефакторинг этого метода ниже, чтобы я мог его модульно протестировать. Я использую mstest с moq, и я знаю, что appsettings - это проблема, наряду с запечатыванием HttpContext .... Любая помощь или мысли (конструктивные) с благодарностью. 

   public void DoClaimSearch(SearchClaimInfo clmRequest)
    {
        var result = claimManager.ClaimSearch(clmRequest);
        if (result.RespMsg.TotalRowCount > Convert.ToInt32(ConfigurationManager.AppSettings.Get("TotalRowCount_Max_ClaimSearch")))
        {
            string ResKey = HttpContext.GetGlobalResourceObject("Global", "info_toomanyrecordsmatch.Text").ToString();
            ResKey = ResKey.Replace("{0}", result.RespMsg.TotalRowCount.ToString());
            View.AddNotification(WidgetNotificationType.Error,ResKey);
        }
        else
        {
            View.SetWidgetResponseData(result.RespMsg.SearchResults);
        }
    }

1 Ответ

1 голос
/ 29 ноября 2011

Вы можете:

Первое решение:

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

Второе решение:

Создать класс для инкапсуляции вызовов этих ресурсов.Какой-то брокер конфигурации.Этот класс будет иметь интерфейс и будет вставлен в конструктор.Это позволит легко издеваться и тестировать.Это добавит абстракцию к доступу к вашим ресурсам.Клиент посредника конфигурации не будет заботиться, находятся ли ресурсы в Resx, .config, HttContext или чем-то еще.

Третье решение:

Пусть конструктор класса извлечет эти значения и назначит их частным переменным-членам, которые можно использовать в вашей функции.Как и в решении 1, это не позволит вызывающему коду узнать об этих значениях конфигурации.Чтобы легко это проверить, есть второй конструктор не по умолчанию, который получает эти значения конфигурации в параметрах.Таким образом, если вы просто используете конструктор по умолчанию, ctor будет вызывать ConfigurationManager и т. Д. Но в ваших тестах вы можете вызвать второй конструктор и передать эти значения (это даже потребует их проверки).

...