Obtaining XML report(s) for assemblies passed to NUnitTeamCity

Hello,

Recently I have faced with a problem related to obtaining XML with results after running tests while performing MSBuild runner. In other words how to get XML with results for specified assemblies with certain tests?
As far as I understand MSBuild tasks while running assemblies with tests determines somehow tests results and I was not able to get this XML. There's no option to specify XmlOutputPath per each assembly. Also it's not possible to specify output for NUnit/NUnitTeamCity in order to get results. Seems this issue already exists in your tracker (State is Open):
https://youtrack.jetbrains.com/issue/TW-4716
Also I detected a few related issues:
https://youtrack.jetbrains.com/issue/TW-5392
https://youtrack.jetbrains.com/issue/TW-5366

At the current moment it's possible to get such result if I run nunit-console with appropriate parameters (/xml:AssemblyResults.xml etc.) but it's preferable to get similar XML while running TeamCity internal tasks (NUnit/NUnitTeamCity) and not to run nunit-console for one more time.

Please let me know when this feature will be implemented.

Also, is there any workaround to get XML report through NUnitTeamCity?

2 comments
Comment actions Permalink

At the moment we do not have any particular plans when this feature will be implemented.
Technically, mentioned xml file is not produced during build. TeamCity reports tests status via interracting with msbuild / nunit api and sending service messages.
Please let me know how exactly do you want to use resulting xml.

0
Comment actions Permalink

>> Please let me know how exactly do you want to use resulting xml.
We need test results to store them on separate system (we are using SonarQube now).

We can run nunit by a command line, but in this case we will loose interaction with Team City during test running and will not be able see test run statistics just-in-time.
So, configuration based on direct run of nunit will be useless and not convinient for developers (preverified check-ins, nightly builds, etc).

That's why we need duplicate configurations for code coverage, instead of using one configuration for different reasons.

0

Please sign in to leave a comment.