1

I am trying to create a unit test for an HtmlHelper that accesses my data layer to get a string. I have looked at a lot of posts around this and I am probably missing something. The problem that I am having is how do I mock the access to my data layer? I usually do my dependency ijection through the constructor, but I cannot here because the html helper needs to be static. So I've setup the injection through a property, but how do I access this from my unit test. Sorry if this is obvious, but its messing me up right now.

Here is what I have -

public static class StringResourceHelper
{

    #region Private Members

    private static IStringResourceService _service;

    #endregion

    #region Public Properties

    private static IStringResourceService Service
    {
        get
        {
            if(_service==null)
            {
                _service = (IStringResourceService)Bootstrapper.Container.Resolve(typeof(IStringResourceService));
            }

            return _service;
        }
    }

    #endregion

    #region Public Methods

    public static string StringResource(this HtmlHelper helper, string label)
    {
        int languageCode;

        if(helper.ViewData["LanguageCode"] == null || !Int32.TryParse(helper.ViewData["LanguageCode"].ToString(), out languageCode))
        {
            languageCode = Constants.LanguageCodes.English;
        }

        return Service.GetString(label, languageCode);
    }

    #endregion

}

How do I mock the Service.GetString call?

2 Answers 2

1

Disclaimer I work at Typemock

If you need to mock/fake static methods and without changing your code you'll need to use Isolator. Faking the method is done using:

Isolate.WhenCalled(() => Service.GetString(string.empty, 0)).WillReturn(/*insert return value here*/);

If you want to check the arguments passed to Service.GetString use the following:

Isolate.Verify.WasCalledWithExactArguments(() => Service.GetString(/* use expected arguments*/);
Sign up to request clarification or add additional context in comments.

Comments

0

To start with I would be weary of any static methods that require a member variable. To me that is a sign that you have a object (likely Singletonly scoped). So my first suggestion would be to promote StringResourceHelper to a none-static class and use DI as normal.

If you can't then does your DI framework of choice support static setter injection? Warning bells go off for me if I see something outside the bootstrap playing with the DI framework as it looks to me as if it is you are using the DI framework as a service locator.

If you can't change the class to be none-static and your DI framework does not support static setter injection then I would either:

Set the DI framework up as part of the tests set up to return mocks or add a setter to StringResourceHelper so it can be controlled.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.