nunit: TestCase and Values do not correctly convert DateTime string in current culture

Converting string into DateTime the TestCase, Values attributes use invariant culture System.Globalization.CultureInfo.InvariantCulture. I expect that when I change the TestExecutionContext.CurrentCulture using SetCultureAttribute for test / test fixture, the converter should use the new culture info. What do you think about?

The following tests fail

[TestCase("12.10.1942")]
[SetCulture("de-DE")]
public void CanConvertStringToDateTimeInCurrentCulture(DateTime dt)
{
     Assert.AreEqual(new DateTime(1942, 10, 12), dt);
}

[Test]
[SetCulture("de-DE")]
public void CanConvertStringToDateTimeInCurrentCulture([Values("12.10.1942")] DateTime dt)
{
     Assert.AreEqual(new DateTime(1942, 10, 12), dt);
}

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 36 (31 by maintainers)

Most upvoted comments

and also ensures that tests run the same way on all machines.

Definitely not suggesting we change that! I’d suggest the culture used is either invariant or explicitly set by the user - I don’t think it’s a good idea to bring CurrentCulture into this at all.

As far as I am concerned, the attributes that feed the test are NUnit code and should be invariant.

Is this not something of an implementation detail? I can understand the confusion of defining a test to be de-DE, and then finding part of that test actually uses Invariant culture. Especially as NUnit is already implicitly converting the string to a DateTime - ignoring NUnit’s own culture definition here seems inconsistent.

ChrisMaddock on Jan 27, 2017

The problem here is that NUnit uses various attributes at different points in the life cycle of the test.

In your case, the TestCase, Test and Values attributes are used to create the test. At a later stage - in the case of a gui, it could be much later - the test is executed. At that point, the SetCulture attribute sets the current culture of the execution thread.

By using a string argument but making the test parameter a DateTime, you’re forcing the conversion to take place at the earliest stage, when the test is created. If you used a string parameter and converted it in your test, it would work as you expect.

Alternatively, you could use a TestCaseSource attribute on a method that yields DateTimes constructed in any way you like.

CharliePoole on Jan 25, 2017