Skip to content
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

Write coverage XML to file #354

Merged
merged 262 commits into from Mar 6, 2019

Conversation

Projects
2 participants
@AirQuick
Copy link
Member

commented Sep 10, 2018

This pull request derives from #353. So needs to be handled after that.


The code coverage feature is not easy to work with.
One of the reasons is that the trace listener prints XML lines to stderr.

This pull request fixes it.
The trace listener now writes XML to a file specified by xspec.coverage.xml system property.

I verified manually that

  • test/run-bats.cmd, test/run-xspec-tests-ant.cmd and test/end-to-end/run-e2e-tests.cmd passed with Saxon-EE 9.7.0.21
  • test/run-bats.sh, test/run-xspec-tests-ant.sh and test/end-to-end/run-e2e-tests.sh passed with Saxon-EE 9.8.0.12 (without test/xspec-215.xspec)
  • bin/xspec.sh -c tutorial/coverage/demo.xspec with Saxon-EE 9.8.0.12 and the saxon EXPath pkg command generated the same coverage report HTML as the non saxon command.

AirQuick added some commits Nov 28, 2018

Merge branch 'master' of git://github.com/xspec/xspec into fix_issue-346
# Conflicts:
#	test/xspec-bat.cmd
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into test_space…
…_cumulative

# Conflicts:
#	test/xspec-bat.cmd
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into rm-pkg-ns-…
…from-xquery-xml

# Conflicts:
#	test/xspec-bat.cmd
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into resolve-ca…
…talog

# Conflicts:
#	test/xspec-bat.cmd
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into resolve-ca…
…talog

# Conflicts:
#	test/xspec-bat.cmd
#	test/xspec.bats
Merge branch 'resolve-catalog' of https://github.com/AirQuick/xspec i…
…nto rm-pkg-ns-from-xquery-xml

# Conflicts:
#	bin/xspec.bat
#	build.xml
#	test/ant/common/generate-build-worker.xsl
#	test/end-to-end/generate-expected.cmd
#	test/end-to-end/generate-expected.sh
#	test/end-to-end/processor/base/compare.xsl
#	test/end-to-end/processor/base/normalize.xsl
#	test/end-to-end/run-e2e-tests.cmd
#	test/end-to-end/run-e2e-tests.sh
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into fix_issue-346
# Conflicts:
#	.gitignore
#	.travis.yml
#	appveyor.yml
#	test/.gitignore
#	test/end-to-end/README.md
#	test/end-to-end/cases/expected/stylesheet/coverage-tutorial-result.html
#	test/end-to-end/generate-expected.cmd
#	test/end-to-end/generate-expected.sh
#	test/end-to-end/processor/html/_normalizer.xsl
#	test/end-to-end/run-e2e-tests.cmd
#	test/end-to-end/run-e2e-tests.sh
#	test/run-bats.cmd
#	test/run-bats.sh
#	test/win-bats/collection.xml
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into test_space…
…_cumulative

# Conflicts:
#	.gitignore
#	.travis.yml
#	appveyor.yml
#	test/.gitignore
#	test/end-to-end/README.md
#	test/end-to-end/cases/expected/stylesheet/coverage-tutorial-result.html
#	test/end-to-end/generate-expected.cmd
#	test/end-to-end/generate-expected.sh
#	test/end-to-end/processor/html/_normalizer.xsl
#	test/end-to-end/run-e2e-tests.cmd
#	test/end-to-end/run-e2e-tests.sh
#	test/run-bats.cmd
#	test/run-bats.sh
#	test/win-bats/collection.xml
#	test/xspec.bats
@galtm

This comment has been minimized.

Copy link
Collaborator

commented on test/xspec-node-selection.xspec in 3c01377 Jan 2, 2019

Would it be clearer to say "x:param child node is used"? The test is about use of href versus child node, and that's how the other x:expect labels are written.

This comment has been minimized.

Copy link
Member Author

replied Jan 2, 2019

Good point. How about "child x:param is used"?
Since the parent scenario's label is "In //x:context...", the speaking context is in x:context. So, strictly speaking, "child x:param's child node is used in evaluating template parameter" would be the correct one. But it confuses what's the point.

This comment has been minimized.

Copy link
Collaborator

replied Jan 2, 2019

In my mind, "child x:param" is a result of the mode you're specifying, while "child node" is the point about how node selection behaves. But the way you wrote "both x:param and href are used" suggests you're aiming for a different way of expressing the outcomes. Maybe just leave the label you started with.

This comment has been minimized.

Copy link
Member Author

replied Jan 3, 2019

Thanks for the clarification.
In this scenario, I wanted to assert this:

  • Although node-selection discards x:context[@href]/child::node(), x:context[@href]/child::x:param (which technically is a subset of x:context[@href]/child::node()) takes effect as template parameter.

In other words, the scenario asserts that template-param is independent of node-selection even when they might look related.
In that sense, this scenario is different from the other scenarios. Let me leave the label as it is.

This comment has been minimized.

Copy link
Collaborator

replied Jan 3, 2019

Yes, leaving it as is sounds good. I see what you're doing now, and it makes sense.

@cirulls cirulls self-requested a review Jan 11, 2019

AirQuick added some commits Jan 28, 2019

Merge branch 'master' of git://github.com/xspec/xspec into coverage-d…
…irect-xml

# Conflicts:
#	test/end-to-end/cases/expected/stylesheet/xspec-rule-result.html
#	test/end-to-end/cases/expected/xspec-rule-junit-norm.xml
#	test/end-to-end/cases/expected/xspec-three-dots-junit-norm.xml
#	test/generate-tests-utils.xspec
#	test/win-bats/collection.xml
#	test/xspec.bats
Merge branch 'master' of git://github.com/xspec/xspec into fix_issue-346
# Conflicts:
#	test/end-to-end/cases/expected/stylesheet/xspec-rule-result.html
#	test/end-to-end/cases/expected/xspec-rule-junit-norm.xml
#	test/end-to-end/cases/expected/xspec-three-dots-junit-norm.xml
#	test/generate-tests-utils.xspec
#	test/win-bats/collection.xml
#	test/xspec.bats

@AirQuick AirQuick added this to the v1.3.0 milestone Feb 11, 2019

@AirQuick AirQuick added this to To do in v1.3.0 via automation Feb 11, 2019

AirQuick added some commits Mar 2, 2019

Merge branch 'master' of git://github.com/xspec/xspec into fix_issue-346
# Conflicts:
#	test/end-to-end/processor/junit/_normalizer.xsl
#	test/end-to-end/processor/xml/_normalizer.xsl
Merge branch 'master' of git://github.com/xspec/xspec into fix_issue-346
# Conflicts:
#	test/xspec-space_stylesheet.xspec

@AirQuick AirQuick merged commit 77bd60a into xspec:master Mar 6, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

v1.3.0 automation moved this from To do to Done Mar 6, 2019

@AirQuick AirQuick deleted the AirQuick:coverage-direct-xml branch Mar 6, 2019

@AirQuick

This comment has been minimized.

Copy link
Member Author

commented Mar 6, 2019

@cirulls
Merged this enhancement.

@cmarchand
I merged two changes in java/com/jenitennison/xslt/tests/XSLTCoverageTraceListener.java recently.

  • One change replaces out.println() with Saxon serializer. I guess this change doesn't affect the maven plugin.
  • The other change (this pull request) stops using System.err. The trace listener now writes the coverage XML to a file specified by xspec.coverage.xml system property. I think the maven plugin needs to adapt to this change, if the plugin collects information from XSLTCoverageTraceListener.

I merged these changes without review, because there were several bugs in this area and it was so obvious that out.println() and System.err weren't viable anymore.
I know little about Java and these changes aren't set in stone. Please feel free to propose further improvement.

@AirQuick AirQuick referenced this pull request Apr 30, 2019

Closed

Release v1.3.0 #563

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.