Failure report is not available in HTML when focusing on a child scenario

[AirQuick]

<?xml version="1.0" encoding="UTF-8"?>
<x:description stylesheet="do-nothing.xsl" xmlns:x="http://www.jenitennison.com/xslt/xspec">

	<x:scenario label="Scenario 1">
		<x:call function="true" />
		<x:expect label="should fail" select="false()" />

		<x:scenario label="Scenario 1-1">
			<x:call function="true" />
			<x:expect label="should fail" select="false()" />
		</x:scenario>

		<x:scenario focus="Focus me" label="Scenario 1-2">
			<x:call function="true" />
			<x:expect label="should fail" select="false()" />
		</x:scenario>
	</x:scenario>

</x:description>

(Note @focus in the Scenario 1-2.)

When you run this scenario, the focused Scenario 1-2 fails as expected.
In the report HTML, however, the entire Scenario 1 is collapsed. You can't see the failure report of its child Scenario 1-2.

Same on XSpec v0.3.

[galtm]

While looking at this, I had a question. I'm not sure if it is a compiler bug or the correct behavior. (It is not a bug in PR #529.) I took a quick look for an existing issue but didn't find one. The question is whether //x:scenario[@focus]/x:pending[x:expect] is supposed to be honored as pending, or whether @focus always takes precedence regardless of the hierarchy. I can't tell from the wiki. My HTML report shows the "UNLESS" listing.

	<x:scenario label="focused scenario" focus="x">
		<x:call function="true"/>
		<x:expect label="should execute assertion" select="true()"/>
		<x:pending label="hide pending expect">
			<x:expect label="UNLESS it is inside x:pending?" select="false()"/>
		</x:pending>
	</x:scenario>

[AirQuick]

Good point. I couldn't find an authoritative answer to it. The behavior seems to have changed at 3366f94 with no tests/details provided.
I personally don't like the focus to override its descendant pendings, whereas I do expect the focus to override its ancestor-or-self pendings as tested in xspec-focus-2.xspec. What do you think?

[galtm]

I don't feel that strongly about this, but I tend to agree with your opinion. If I'm trying to write a set of tests first and then code the functionality, then pending status might prevent a hard error that would otherwise occur before the functionality has been coded. I can always choose not to use @focus or choose to temporarily comment out assertions that would cause a hard error, but then it seems like the tools are not as helpful as they could be.

On the other hand:

• If @focus is supposed to override @pending and x:pending regardless of hierarchy, it would be great to document and test that behavior.
• Do you know if there are precedents worth following in other testing dialects, such as the RSpec package on which XSpec was originally based? I have not used RSpec, and I don't know if this kind of interaction occurs there or how it gets handled. RSpec does seem to have similar concepts, though, of pending and filters.

[AirQuick]

Filed #575.

• If @focus is supposed to override @pending and x:pending regardless of hierarchy, it would be great to document and test that behavior.

Agreed. I think we need the test, whatever the current behavior is.

• Do you know if there are precedents worth following in other testing dialects, such as the RSpec package on which XSpec was originally based?

Good point. Unfortunately so far I don't know if the other BDD flavors have a similar built-in facility.

[cirulls]

In Jasmine (a BDD framework for JavaScript) focused tests always take precedence over unfocused tests. I am not sure about other testing frameworks though.

In general, I would expect the focus tests to be honoured so I would suggest to implement this behaviour. It would be good to test the current behaviour though.