Control character encoding is inconsistent between TestCase[Source] and TestFixture[Source].

[estrizhok]

Given the following class:

[TestFixture("X\nY\r\nZ")]
public class Tests
{
  public Tests(string x) { }

  [TestCase("X\nY\r\nZ")]
  public void TestCase(string p1) { }
}

NUnit test exploration produces the following results (I removed irrelevant elements and attributes):

<test-suite type="ParameterizedFixture"
                  fullname="TestProject25.Tests"
                  classname="TestProject25.Tests">
  <test-suite type="TestFixture" 
                    name="Tests(&quot;X&#xA;Y&#xD;&#xA;Z&quot;)"
                    fullname="TestProject25.Tests(&quot;X&#xA;Y&#xD;&#xA;Z&quot;)"
                    classname="TestProject25.Tests">
    <test-suite type="ParameterizedMethod" 
                      name="TestCase" 
                      fullname="TestProject25.Tests.TestCase" 
                      classname="TestProject25.Tests">
      <test-case name="TestCase(&quot;X\nY\r\nZ&quot;)"
                       fullname="TestProject25.Tests(&quot;X&#xA;Y&#xD;&#xA;Z&quot;).TestCase(&quot;X\nY\r\nZ&quot;)" 
                       methodname="TestCase" 
                       classname="TestProject25.Tests" />
    </test-suite>
  </test-suite>

Note different ways to present control characters that appear inside the values for TestFixture and TestCase.

[jnm2]

Great repro, thank you!

@nunit/framework-team It seems to me that name should be a simple XML encoding of the display string. If we like to display the text \n for (char)10, the XML should also have \n. Am I thinking correctly?

[rprouse]

@jnm2, I am not sure what you are saying, sorry 😕

Personally, I think the test-suite should be formatted the same as the test-case, but I would like to figure out why we encoded it in the first place.

[CharliePoole]

I think it's encoded because we can have any arbitrary characters in it based on user string arguments or special names that the user gives to tests. In fact, I recall some bug that was fixed having to do with the latter.

[rprouse]

If that is the case, then we should probably be encoding the test-case the same way, it could have the same arbitrary strings.

[jnm2]

@rprouse Sorry! So taking a newline for example, the question in my mind was between encoding as 

 so that when deserialized, you actually get a newline; or, encoding it as the xml string \r\n so that when deserialized, you actually get the display string backslash-r-backslash-n. I'm thinking it should be the latter?

[rprouse]

I am curious how actual newlines appear in 3rd party runners like the adapter. We will want to check the behavior at least in the adapter with whatever we decide.

[CharliePoole]

Even in our own console runner, which gets it from the XML.

[manfred-brands]

Both TestSuite.AddToXml and TestMethod.AddToXml call into the same base class method Test.PopulateTestNode which calls XmlExtensions.EscapeInvalidXmlCharacters that escapes unprinitable characters into unicode. This does not create the " escapes. This is created by the XmlWriter.WriteAttributeString

So the encoding path is the same, but the name is not:

In the test-suite the name contains an actual new-line character, but in the test-case it contains the '\n' sequence.

The first is formed by the TypeHelper.GetDisplayName
The latter is formed by indirect calls to TestNameGenerator.GetDisplayString.

Looks like those to need aligning or better become one.

[stevenaw]

I think the milestone got missed for this. I've added it now and will add it to the v4 changelog shortly