JUnit XML tests mis-present the test execution time from test cases.
Summary
For a test that produces JUnit XML testcase
output with an execution time, the GitLab UI presents the value as milliseconds. It is not. It should be presented as seconds.
The base specification taken from the original site (and now migrated to github) defines the testcase
time
attribute as being in seconds: https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd
<xs:attribute name="time" type="xs:decimal" use="required">
<xs:annotation>
<xs:documentation xml:lang="en">Time taken (in seconds) to execute the test</xs:documentation>
</xs:annotation>
</xs:attribute>
Steps to reproduce
Produce JUnit XML with the following content:
<?xml version='1.0' encoding='UTF-8'?>
<testsuites errors="0" failures="1" skipped="0" tests="1">
<testsuite errors="0" failures="1" hostname="me.gerph.org" id="1" name="xml-lint" skipped="0" tests="1" timestamp="2019-01-18T08:07:00">
<testcase classname="lint" file="src/style/input.xml" line="15" name="Lint src/style/input.xml" time="0.259">
<failure message="Element section content does not follow the DTD, expecting (p | subsection | subsubsection | category | swi-definition | service-definition | upcall-definition | message-definition | command-definition | sysvar-definition | error-definition | entry-definition | vector-definition | extended-example | import)*, got (p fixme )" type="validity error"></section>
^
</failure>
</testcase>
</testsuite></testsuites>
Example Project
gerph/unhelpful-junitxml-handling!1 (closed)
What is the current bug behavior?
In the UI, when you click on the Lint src/style/input.xml
test you see:
Execution time: 0.259 ms
What is the expected correct behavior?
In the UI, when you click on the Lint src/style/input.xml
test you SHOULD see:
Execution time: 0.259 s
Output of checks
This bug happens on GitLab.com. It also happens on locally hosted GitLab CE.
Results of GitLab environment info
N/A - happens on gitlab.com.
Results of GitLab application Check
N/A - happens on gitlab.com.
Possible fixes
-
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/reports/components/modal.vue#L50
- There should be another fieldtype for seconds (presuming that other users still use milliseconds in this report code)
- As an aside,
miliseconds
should be corrected tomilliseconds
.
-
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/reports/store/state.js#L46
- Should be updated to report a seconds fieldtype for the execution time.
-
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/reports/store/state.js#L46
- Corrected for rendering of seconds.
Recommend:
- checking implementation in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20576/diffs to ensure that there is no assumption that the backend uses milliseconds (brief examination implies this is the case)
- checking implementation in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20936/diffs to ensure that the only assumption is that the value supplied by the back end is that of milliseconds (when in fact it is seconds).
- once confirmed that the only discrepency is in the presentation, just replace the front end uses (in the latter MR) with seconds, rather than milliseconds (or miliseconds).
If it is just a discrepency between the FE and BE, then the change is nice and small. If the BE assumes it is presenting milliseconds, or has been storing values labelled as milliseconds when they are really seconds, then I presume that this will be more involved and introduce database migrations for stored values that were erroneously stored as ms but are actually seconds.