-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XML output misses contexts #62
Comments
We're seeing this too. It's causing our Bamboo server to miss tests as many tests appear to be named the same in the generated junit xml file. Downgraded to [email protected] for now as this doesn't exhibit this issue. |
Same problem for us on Bamboo - with latest reporter version, out of 750 tests, Bamboo, after parsing, shows only 570 tests. With 2.2.2 Bamboo was showing a more realistic number (still not everything). |
Thanks for the report |
+1 would love to see a fix for this, or a tip on where to look if I were to try a PR ;) |
I noticed this too after upgrading, the classname used in the XML is only the top level "describe" any nested "describe" names are omitted, so tests group under the one level instead of splitting out. |
This error was introduced by e4f7ebd. In order to generate Sonar compatible report, one have changed generation of classname parameter from |
Played with this locally and found that prefixing the test description with the parent suite names, ended it with the @osherx expected output test name. From line #125 var spec = suites[browser.id].ele('testcase', {
name: result.suite.join(' ') + ' ' + result.description, // was result.description
time: ((result.time || 0) / 1000),
classname: getClassName(browser, result)
}) I could possibly open a PR with that fix if @dignifiedquire thinks it looks good? |
👍 for the idea of getting the nested describes working. We are also for now resorting to 0.3.3 downgrade most likely soon. I am writing a simple test for testing whether I could extinguish the bug; made by using that older working result.suite.join(' ') with enough sanity testing also so not to introduce new creepers. :) But so relative-newbie still (mostly in the tooling and philosophy of practical opensource) that I'll most likely be having a PR earliest 2016, if any. |
@phillipj sorry for the late reply but yes that sounds good |
Can this be tested by test suites within the reporter? Ie. does karma-junit-reporter itself have tests? I was also a bit hesitant in putting forward a blind PR. |
@dignifiedquire Hi, has there been progress in this individual issue either through fix or the latest version containing changes? There's at least one pull request but the thing is that it should be tested with at least some known instances where the buggy 0.3.3 (-> onwards) name flattening happens. I didn't have test data at hand to test the PR. |
+1 |
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
This fixes issue reported in karma-runner#62 where test names doesn't include parent test suites in the generated report. Also created minimal unit test setup.
having: test suite that provides the following mocha output:
expected: testcase name to include the context, like:
<testcase name="Sender using it get request should not fail" time="0.816" classname="Android_4_1_2_(Android_4_1_2).Sender">
but got:
<testcase name="should not fail" time="0.816" classname="Android_4_1_2_(Android_4_1_2).Sender">
or, alternatively - if the format allows (im not sure what the JUnit xml spec sais) - then let
suite
nest contextsuite
elements.my personal hunch is that the first would be easier, and parsed by all builders that open JUnit xml files the same way they are parsed now :)
You can also look at failed tests of this build:
https://circleci.com/gh/el-net/bs_karma_eval/21
correspond to the code here:
https://github.com/el-net/bs_karma_eval
The text was updated successfully, but these errors were encountered: