nunit / teamcity-event-listener

NUnit Engine extension that helps integration with teamcity
MIT License
11 stars 10 forks source link

Test names are aliased (different tests misreported as instances of the same test) when using long assembly names. #15

Open einert opened 8 years ago

einert commented 8 years ago

The following is a representative example of a test name as captured from nunit3-console output by TeamCity: [Deepish.Namespaces.Due.To.Established.Project.Practices.EngineeringModulinator.UnitTest.dll] Deepish.Namespaces.Due.To.Established.Project.Practices.EngineeringModulinator.UnitTest.RelatedTestsGroup.ConfigureContainer_Always_RegisterType(Deepish.Namespaces.Due.To.Established.Project.Practices.EngineeringModulinator.IEngineeringModulinator)

The bit in brackets is the assembly, which serves as the suite name. Next up is the fully qualified name of the test, with a fully qualified parameter. Note that the test is already "scoped" to the assembly, so in this case, the full namespace is not necessarily required to uniquely identify the test.

When this comes up against the hard 256-character limit for test names, the name is inevitably truncated.

Counting to 256 gets us almost to the last 's' in the final "Namespaces", so any reported summaries of test results will be subject to aliasing, i.e. other instances of this parametrized test that check registration of other types in the same namespace will count as a repeat run of the same test, rather than a separate test.

Even excluding the "suite" identifier, the fully qualified test name with parameter alone is stretching the limits a bit, at 248 characters.

Barring a change that takes away the 256-character limit, is there any way to control how test names are identified in TeamCity? As it stands, the specifics at the end of the test name (i.e. expectations, parameters) are clipped for the benefit of the (in my case, somewhat more redundant) specifics at the start of the name.

NikolayPianikov commented 8 years ago

We have a set of issues https://youtrack.jetbrains.com/issue/TW-44130 https://youtrack.jetbrains.com/issue/TW-10480

Also we can't change rule because backward compatibility will be broken. Try to use additional NUnit command line argument "--test-name-format". See examples:

` [TestCase("FIXED", ExpectedResult = "FIXED")]

[TestCase("{m}", ExpectedResult = "TestMethod")]

[TestCase("{n}", ExpectedResult = "NUnit.Framework.Internal.Tests")]

[TestCase("{c}", ExpectedResult = "TestNameGeneratorTests")]

[TestCase("{C}", ExpectedResult = "NUnit.Framework.Internal.Tests.TestNameGeneratorTests")]

[TestCase("{M}", ExpectedResult = "NUnit.Framework.Internal.Tests.TestNameGeneratorTests.TestMethod")]

[TestCase("{m}_SpecialCase", ExpectedResult = "TestMethod_SpecialCase")]

[TestCase("{n}.{c}.{m}", ExpectedResult = "NUnit.Framework.Internal.Tests.TestNameGeneratorTests.TestMethod")]

[TestCase("{x}", ExpectedResult = "{x}")]

[TestCase("{n}.{c.{m}", ExpectedResult = "NUnit.Framework.Internal.Tests.{c.{m}")]

[TestCase("{m}{a}", ExpectedResult = "TestMethod")]

[TestCase("{i}", ExpectedResult="THE_ID")]`

I hope it will help.

einert commented 8 years ago

@NikolayPianikov That looks very promising, but bizarrely enough this seems to only affect the very end part of the name; the test case itself.

Running with NUnit 3.4.1 (and the --teamcity argument), in the ##teamcity service messages, the full namespace is still included regardless (and in addition to the format here). The output is <full namespace>.<test case formatted according to given format string>.

So, if I specify the format {m} - only the test name, I actually get the same output as without any format given; full namespace plus the test name. If I specify "plz_{m}", I get <namespace>.plz_<test name>.

Providing {M}, which based on the apparent intent seems like the full name (default format), I actually get <full namespace>.<full namespace again>.<test name>.

Back to NUnit support then?

NikolayPianikov commented 8 years ago

Yes, I've checked it is not working unfortunately. No, I think I can see it at first.

As workaround you could use this nunit wrapper, which replaces the console output: nunitWrapper.zip

Just update nunit3-console.exe.config Change the path to the correct path in the element: <add key="executable" value="C:\Program Files (x86)\NUnit-3.4.1\bin\nunit3-console.exe" />

And specify TC nunit3-console path to your nunitWrapper

Src code is here: https://github.com/DevTeam/wrapper

einert commented 8 years ago

OK, thanks a lot. I will have a look and see whether this could do the trick, and whether I am able to shoehorn it into our repository structure and nuget-based setup.

CharliePoole commented 8 years ago

@NikolayPianikov What about dropping the assembly name and using [n] instead, where n = the part of the test id that precedes the hyphen?

NikolayPianikov commented 8 years ago

@CharliePoole I am not sure that I understand your idea. TC extension uses the "fullName" attribute to create message. The TC extension does not add the name of assembly directly. The TC creates full test names using 2 messages:

teamcity[testSuiteStarted name='MyAssemblyName']

teamcity[testStarted name='MyNamespace.TestFixture.MyTest']

So TC creates name "MyAssemblyName:MyNamespace.TestFixture.MyTest" and user can't change this rule on the TC.

The argument "--test-name-format" changes "name" and "fullname" attributes. The "fullname" attribute is a combination of a full class name and a "name" attribute. So when I add the argument --test-name-format={m}_aaaa:

CharliePoole commented 8 years ago

@NikolayPianikov I was not suggesting the user could do this, but that you could. I assumed the extension create the concatenated name. If TC does it then of course you can't change the format.

Regarding the test name format, the argument is only designed to change test names. It doesn't affect the name of the class.