TestFilterBuilder builds invalid XML

[jnm2]

(Updated)

This implementation mishandles surrogate pairs. Control characters other than tab, carriage return and line feed cannot be represented in XML and should throw, IIRC. (See nunit/nunit3-vs-adapter#484.)

nunit-console/src/NUnitEngine/nunit.engine/Services/TestFilterBuilder.cs

Lines 82 to 90 in af89a43

	private static string XmlEscape(string text)
	{
	return text
	.Replace("&", "&")
	.Replace("\"", """)
	.Replace("<", "&lt;")
	.Replace(">", "&gt;")
	.Replace("'", "&apos;");
	}

GetFilter() should be using XmlWriter.Create to a StringWriter. This will not only get us out of the responsibility of implementing the XML spec, it will probably also result in some significant performance gains. (Judging by the chained string.Replace calls.)

(Test names containing control characters cannot be represented in XML without first encoding using base64 or something custom. This will need to be dealt separately with in the framework.)

@nunit/engine-team Does this seem right to you? Can we let @MatthewBeardmore get started on this if he is interested?

[ChrisMaddock]

Yep, looks good to me!

[jnm2]

Wait a second, I remembered wrong. Control chars are totally banned in XML and cannot even be escaped.

This means that test names with control characters cannot be represented in XML and would have to be specially encoded. For example, base64 like we do for binary content.

[jnm2]

I'm slowly catching up to where you all are. This issue might depend on nunit/nunit#3063 (comment).

[OsirisTerje]

Base64 sounds fine to me

[jnm2]

@OsirisTerje I'm currently thinking we wouldn't even need additional encoding such as base64 if the framework and adapter ensure that there's no such thing as a test name with control characters in it: nunit/nunit#3063 (comment)

[OsirisTerje]

I don't think this is up to us to decide - just because we use XML as an intermediate information carrier. The adapter has to accept whatever test name that comes down, and the source based discovery mechanism will use these names for the list that will be passed down to the adapter. They will be part of the FQN - if we can't persuade MS to also ignore these characters, which I doubt. So the only option I can see is that we need to encode them before we use the XML to send them between adapter and engine, and further.

[jnm2]

@OsirisTerje I hear what you're saying. We should probably raise this question about parameterized FQNs. However, if NUnit Framework decides that all test names will be prefixed with T- by default, that's a decision I do think is up to the framework. Likewise, if the framework replaces every A with a B in the test names it generates, that's also fine (though nonsensical) so long as the framework is self-consistent.

So why not replace control characters in the name and fullname attributes, and send a base64-encoded fqn attribute to make it possible for the adapter to losslessly interface with VSTest and source-based discovery?