Open psss opened 5 months ago
@psss I quickly checked a junit format and it seems like there is infrastructure to support subtests/phases classname - could be used for a parent test name name - could be used for a subtest/phase
According to
https://www.ibm.com/docs/en/developer-for-zos/14.2?topic=formats-junit-xml-format
<testsuite>
has child elements <testcase>
, not <testsuite>
again. We should be clear in which artifacts these phases should appear and how those artifacts are going to be used. Do we know if the proposed XML with nested <testsuite>
elements would be compatible with ReportPortal for example?
FYI, I just tried to import https://github.com/testmoapp/junitxml/blob/main/examples/junit-basic.xml to RP and it went well, creating nested structures for testsuites. So at least from the RP perspective we may be fine.
Note: Beakerlib executes BEAKERLIB_COMMAND_REPORT_RESULT
only if TESTID
is set (https://github.com/beakerlib/beakerlib/blob/4321c54e2e99f74b91c9376aa4324dafd0300c3d/src/testing.sh#L1075) - we don't set it in tmt yet.
Just FYI, I was experimenting with a nested structure of <testsuite>
using a junit-xml but the library does not support it. There are unmerged patches that add the support for nested <testsuite>
structures (quickly tested - they seem to work fine), but the library is outdated and unsupported (the last commit was 4 years ago).
I have been searching for suitable alternative libraries, but so far, I haven't found any. Any ideas?
Doing a fallback to own implementation should not be that hard, note that there is a nice way via attr/cattrs we use in Testing Farm and @janhavlin was working on it and could help porting it to tmt:
Note breakers is able to produce the journal.xml in the breaker format as well as in the xunit. However, I was recently contacted by someone who was having an issue where the respective xml python module was missing which causes just an error and the xml file not being created. It might be good if tmt was able to parse the journal.meta, i.e. to use the beakerlib's code to transform it (using the journalling.py).
Doing a fallback to own implementation should not be that hard, note that there is a nice way via attr/cattrs we use in Testing Farm and @janhavlin was working on it and could help porting it to tmt:
Regarding our implementation of the JUnit XML library, I was thinking that we might be able to directly use the junit_xml (approximately just 400-lines of code + unit tests).
We could apply the necessary patches for "test suite inside a test suite", clean up the code, remove Python2 support, and add the type annotations.
Then it should very easily integrate into the TMT. The license for junit_xml is the same as for TMT - the MIT license:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
We would likely be fine by simply adding the copyright notice to the library file header and referencing to the original project repository.
What are your thoughts on this? Do you think this could be a viable solution?
As discussed on the stakeholder meeting, there are use cases related to tracking individual results of test "phases". These can be created using one of the following ways:
beakerlib
phase usingrlPhaseStart
andrlPhaseEnd
rstrnt-report-result
to submit a subresultWhen run in
Beaker
, therlPhaseEnd
command called during abeakerlib
test execution actually callsrlReport
which usesBEAKERLIB_COMMAND_REPORT_RESULT
command to report the result and, if I'm not mistaken, this defaults to usingrstrnt-report-result
. @sopos, please correct me if I'm wrong.The effect is that each
beakerlib
phase andrstrnt-report-result
call create a "subresult" which is shown in theBeaker
web interface under the actual test. The proposal is to add a similar support for subresults totmt
.Here are some more ideas caught from the brainstorm:
BEAKERLIB_COMMAND_REPORT_RESULT
and perform necessary actions on the guestcheck
attribute)avc
failures for each test phase separatelyjunit
format as the spec does not know subresultsAll in all it seems this would bring a substantial level of complexity (currently the test granularity was simply defined by the test metadata definition for each test) so we should discuss this well before jumping into the implementation.
Base Work
Report Plugins