How to set UserLanguages for unit tests (using mocked http contexts)? - asp.net

Question

I'm doing unittests for an asp.net application. Due to how the class I'm currently testing is designed it uses multiple threads and thus manually sets the language for one of the threads:
Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(HttpContext.Current.Request.UserLanguages[0]);
For this to work I'm mocking the httpcontext by using the following class in the unittests before I run the class that contains the above code:
public class HttpContextMock
{
public static HttpContext MockedHttpContext()
{
var httpRequest = new HttpRequest("", "MyUrl", "");
var stringWriter = new StringWriter();
var httpResponse = new HttpResponse(stringWriter);
var httpContext = new HttpContext(httpRequest, httpResponse);
var sessionContainer = new HttpSessionStateContainer("id", new SessionStateItemCollection(),
new HttpStaticObjectsCollection(), 10, true,
HttpCookieMode.AutoDetect,
SessionStateMode.InProc, false);
httpContext.Items["AspSession"] = typeof(HttpSessionState).GetConstructor(
BindingFlags.NonPublic | BindingFlags.Instance,
null, CallingConventions.Standard,
new[] { typeof(HttpSessionStateContainer) },
null)
.Invoke(new object[] { sessionContainer });
return httpContext;
}
Now the problem is even though I get a valid httpcontext the command
HttpContext.Current.Request.UserLanguages
Always returns null.
So my question is what can be done in order to ensure that the UserLanguages return at least 1 entry?

Answer 1

Mocking out HTTPContext isn't easy as you just found out.
Why not avoid that altogether?
Instead of
Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(HttpContext.Current.Request.UserLanguages[0]);
You could do something like
Thread.CurrentThread.CurrentUICulture = _ContextSpecificSettings.Language;
Where _ContextSpecificSettings is an instance of a class you code yourself. Could be something like:
class ContextSpecificSettings
{
HTTPContext _HTTPContext;
public ContextSpecificSettings()
{
_HTTPContext = HTTPContext;
}
public string Language // used string but you would of course use here whatever type is used in UserLanguages
{
get { return _HttpContext.Current.Request.UserLanguages[0]; }
}
}
Now, instead of trying to mock the HTTPContext, you only have to mock/stub your own ContextSpecificSettings class. Which is much easier to do because all you have to mock/stub is returning the language you want to use in your test.
All that is left to do is to ensure that the class containing that assignment to Thread.CurrentThread.CurrentUICulture gets its hands on an instance of your ContextSpecificSettings class. You can do that using simple constructor injection. For example:
class SomeThreadUsingClass
{
ContextSpecificSettings _Settings;
public SomeThreadContextUsingClass(ContextSpecificSettings useThisSettingsInstance)
{
_Settings = useThisSettingsInstance;
}
public Int SomeMethodUsingLanguage()
{
// <snip>
Thread.CurrentThread.CurrentUICulture = _Settings.Language;
// <snip>
return Whatever;
}
}
When you instantiate SomeThreadUsingClass in your actual code, you pass it a (new) instance of the ContextSpecificSettings class. When you instantiate SomeThreadUsingClass in a test, all you have to do is pass it an instance an ContextSpecificSettings Mock/Stub class.
By the way, this is the same technique as I described in Property.Settings.Default makes it hard to unit test any method that uses it