I am well aware that what I am looking to do is not currently possible, so I am looking for a workaround.
First of all, assume a microservice-based, highly modular application system. Each microservice has its own unit tests that are run in its build pipeline, the results are published to Azure DevOps - no problems at this point.
However, there is a need to run some integration (almost end-to-end) tests (let's call it the integration test suite) on a properly deployed application system. That is done on a designated environment (let's call it the integration test environment). The test suite would be executed in several different scenarios, so the output needs to reflect that (this simply means that if there are 4 scenarios, the test result output file will have 4 test suites).
Aside from that, there must be a directly visible link between application system releases and their test results.
In order to achieve this, there is a release pipeline, where the first three stages are: Deploy to DEV, Deploy to INT and Run Integration Tests.
Naturally, the PublishTestResults task is used to present a nice overview of the integration test results. The integration test orchestrator application is generating one JUnit XML/scenario and at the end of testing they are made available to the pipeline.
With that said, here comes the problem: there is a need to present certain statistics about the tests run in each scenario/suite (more interesting stuff than X/Y tests succeeded in Z seconds).
I know that Jenkins CI seem to follow the JUnit XML format described by Dirk Jagdmann, namely that a <testsuite> element can have a <system-out> element and this would appear on the test suite visualization.
Unfortunately (!), Azure DevOps PublishTestResults task only reads <system-out> under individual <testcase> elements (the link above shows the result format mapping). The irony is that the test suite and test case blades are rendered mostly the same - they both have the Debug section where you have an accordion with Error message, Stack Trace etc. (which will not be read/populated for <testsuite> though).
The same applies to JUnit format extensions that would allow referencing extra attachment files in the XML.
Now, if this were a build pipeline, I would not care and just use the PublishBuildArtifacts task to add some .TXT attachments (one per scenario/suite) and call it done. However, this task cannot be used in a release pipeline.
I do need the extended summary/statistics per suite and I cannot have them somewhere in the XML, which can be downloaded after taking several possibly obscure steps. This automatically rules out uploading them somewhere else - if the CI/CD is in Azure DevOps, then everything about it should stay there.
I have full control over the test result XML generation.
