1

I have looked at a lot of examples, but in this case I wish to get a fresh set of eyes on refactoring this method below so that I can unit test it. I'm using mstest with moq and I know that the appsettings is a problem, along with the HttpContext being sealed.... Any help or thoughts (constructive) is greatly appreciated.

   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);
        }
    }
Adam Lear
  • 38,111
  • 12
  • 81
  • 101
Tom Stickel
  • 19,633
  • 6
  • 111
  • 113

1 Answers1

1

You could :

First solution:

Pass the two configuration values via a parameter to the method. Wether this is a good idea depends on where that method is called. It might not be a good idea design wise but it will be very easy to test (just send hardcoded values for those parameters in your tests).

Second solution:

Create a class to encapsulate calls to these resources. Some sort of configuration broker. This class would have an interface and be injected in the constructor. This will make it easy to mock and test. It will add an abstraction to accessing your resources. The configuration broker client will not care if the resources are in a Resx, .config, HttContext or anything else.

Third solution:

Have the class's constructor retrieve those values and assign them to private member variables that can be used in your function. Similar to solution 1, this will prevent the calling code from knowing about those configuration values. To easily test this, have a second non-default constructor that receives those configuration values in parameters. This way, if you simply use the default constructor, the ctor will call the ConfigurationManager, etc. But in your tests you can call the second constructor and pass those values in (this will even the need to mock those).

Gilles
  • 5,269
  • 4
  • 34
  • 66