fix(junit): Add file path in output #1601
Conversation
|
Uploading stable diff file for composer patches. |
acoulton
left a comment
There was a problem hiding this comment.
Thanks for the contribution @klausi
I've checked at https://github.com/testmoapp/junitxml?tab=readme-ov-file#example (closest thing there is to a JUnit spec) and can see the file attribute is supported on <testcase> so we'd be happy to add this.
I think it does need a slightly different implementation, and the example outputs in https://github.com/Behat/Behat/blob/master/features/junit_format.feature also need to be updated with the new attribute to pass the tests.
If you have time to work on this, that would be great :)
| 'failures' => $stats[TestResult::FAILED], | ||
| 'errors' => $stats[TestResult::PENDING] + $stats[TestResult::UNDEFINED], | ||
| 'time' => $this->durationListener ? $this->durationListener->getFeatureDuration($this->currentFeature) : '', | ||
| 'file' => $this->currentFeature->getFile(), |
There was a problem hiding this comment.
I think for consistency this would need to be a relative path the same as the file attribute on the <testcase node.
Currently that is calculated internal to the JUnitScenarioPrinter
but it would probably be better to extract that rather than duplicating it...Note also that it appears Gherkin does not guarantee the file is defined - ->getFile() can be null|string. I have to say I'm not sure why/when it could be missing... The scenario printer therefore only adds a file attribute if there is a file to report.
|
You are absolutely correct, thank you for the pointers! I would probably just copy the file handling code. You know the golden rule of software engineering: duplicating simple code once is fine and avoids abstraction complexity. The third time you want to copy - then you do the refactor :-) I won't have time to work on this right now as I'm busy with other things. Anyone feel free to pick this up! |
|
You're absolutely right about early abstractions, I was just conscious that we also "relativise" paths for the pretty and progress formatters and suspected that might also be duplicated (or abstracted). Looking at them now, I see they actually have slightly different logic. They show paths relative to the behat I think it would probably be better if the JUnit |
Junit support for the file path is missing, adding it here.