Issue with code Coverage Report in 3.0.3

[birdya22]

I have a problem with the code coverage report. Depending on the order in which I run my test scenarios, the code coverage report differs, even though I'm executing exactly the same set of test scenarios in both cases.

I've created a simple test case using 2 xslt functions and have 2 xspec test files which call them in the opposite order. The coverage report from Test01 is wrong and the coverage report from Test02 is what I expect. (Files are in the attached zip).

One function has xsl:choose as the first element and the other has xsl:variable.
The difference in the coverage xml seems to be the traceableId="1" value:
uqname="Q{http://www.w3.org/1999/XSL/Transform}choose" - Test01 (calls the choose function first)
class="net.sf.saxon.expr.instruct.TraceExpression" - Test02 (calls the variable function first)

Adrian
CodeCoverageTest.zip

[galtm]

Thanks for the clear description and ZIP-file. I see that the report from Test01 is wrong and will try to determine why.

[galtm]

Hi, Adrian. I have an idea for a fix, but it will take me some time to qualify and test it properly. If you're interested in trying it sooner with your real code, you can get the .class file and the .xsl file from https://github.com/xspec/xspec/pull/1918/files . If you need help getting the files or incorporating them into your XSpec installation, let me know more about how you are running XSpec (e.g., command line or one of the options listed at https://github.com/xspec/xspec/wiki/Running-with-Oxygen).

If you try it, please let me know how it works out!

[birdya22]

Hello,
I've tried out your changes and they look better to me with my code - I did a similar thing to the example I uploaded and started 2 different test scenarios at different functions and the generated coverage html was the same in both cases.
However I am still seeing some things I don't expect (which are probably unrelated to your change). It is mainly inside xsl:when elements where I put the whole xsl:when element on a single line with either a text value or a tvt as the contents. I'm seeing the whole line missed in some cases and in others the xsl:when element is missed but the content is hit. You can see a simple example is if you change the
<xsl:when>
<xsl:text>1</xsl:text>
</xsl:when>
in the xsl I supplied to <xsl:when>1</xsl:when> on a single line. I get the xsl:when line showing as missed.
Would you like me to raise another issue for this and provide more examples?

Finally, I've seen your Saxon issue https://saxonica.plan.io/issues/6295 about xsl:sequence - are we waiting for a relase later that 12.4 for this fix - I am getting xsl:sequence elements shown as missed.

Adrian

[galtm]

Thanks for trying my changes and reporting back!

inside xsl:when elements where I put the whole xsl:when element on a single line with either a text value or a tvt as the contents

Yes, please raise a separate issue for this. I logged an item with Saxonica, https://saxonica.plan.io/issues/6405, which could help me understand the situation you mentioned. XSpec uses a Java API related to the saxon:column-number extension function, and I'm hoping that clarity about saxon:column-number will help with the actual XSpec code.

About Saxonica issue 6295: Yes, we're waiting for a fix in a release later than 12.4.

[birdya22]

Amanda,
I will raise another issue, but I can add a bit more detail about the column-number issue after putting some diagnostics in coverage-report.xsl. Saxon gives the wrong column-number if the enclosing element (whatever it is e,g, xsl:when, xsl:otherwise with expand-text or your own element) includes any attributes, but only when using the tiny tree model (there is a separate issue which I will raise with Saxonica about the fact that setting -tree:linked doesn't actually use the linked tree when loading the source document - it does use the linked tree for loading any subsequent documents via doc() or unparsed-text().
I will provide an test test with various scenarios in it.

[galtm]

Adrian, thanks a lot for raising #1920 and for your observations about the presence of attributes and the tree models! I appreciate your jumping into the Saxonica discussion.