Files with no failures get a "passing" testcase

[samlev]

This fixes JUnit parsing errors which treat no testcases as a failure (e.g. Atlassian bamboo).

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[X] Other, please explain:

On files that pass, a "passing" testcase should be added. Without any passing testcases, some JUnit parsers will fail, claiming that there are no tests.

This was unofficially reported here: #16 (comment)

This pull request ensures that a passing testcase is added to a testsuite if there are no failures.

What changes did you make? (Give an overview)
Added empty "passing" testcase to JUnit formatter when a file has no messages.

Is there anything you'd like reviewers to focus on?
No

[jsf-clabot]

All committers have signed the CLA.

[aladdin-add]

LGTM, thanks for the contributing!

[not-an-aardvark]

I'm not very familiar with the JUnit format. What does the tests value mean in this context? Would it make sense for the value to always be 1?

[samlev]

"Tests" refers to the number of tests run. In an instance of multiple failures, "tests" and "failures" would always be the same. In the case where there's no failures, we just want to record that a test has been run and passed. With proper unit testing, a suite will have the same value for "tests", no matter how many pass or fail, but because linting doesn't explicitly list every test run and passed for each file, only the places where it fails, and because the same "test" may fail in multiple locations, the number of tests to report should either be a pass for the whole file, or the number of failures.

…

On 31 Oct. 2017 12:34, "Teddy Katz" ***@***.***> wrote: I'm not very familiar with the JUnit format. What does the tests value mean in this context? Would it make sense for the value to always be 1? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9547 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcOgge_N4kT2lV07xtenkC4ugva4nZEks5sxocjgaJpZM4QL8qO> .

[not-an-aardvark]

Closing and reopening this PR to restart the Appveyor build. (We had an unrelated issue where the build was failing on master today, and I think this PR was created while that was happening.)

[ilyavolodin]

Thanks for PR!

[platinumazure]

Totally separate issue: Is it worth having a CLI option that would allow all files to be included in input and shown in formatters, even those with no linting errors? I would hate to see that for a formatter like stylish, but it could be interesting or useful for formatters like JUnit.

[not-an-aardvark]

I think formatters already have access to this information. Do you mean the command-line flag would trigger a behavior change in the formatters themselves?