search

expath / xspec

Automatically exported from code.google.com/p/xspec
MIT License
40 stars 43 forks source link

test="self::bogus" always succeeds #5

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This scenario always succeeds:

  <x:scenario label="This test should fail">
    <x:context>
      <it-doesnt-really-matter/>
    </x:context>
    <x:expect label="self::bogus" test="self::bogus"/>
  </x:scenario>

The test doesn't make much sense, but this was the style of the first tests
that the user wrote.

Original issue reported on code.google.com by dev.xspec@menteithconsulting.com on 1 Apr 2009 at 8:32

GoogleCodeExporter commented 9 years ago 
The user probably meant to write:

  <x:expect label="self::bogus" test="boolean(self::bogus)" />

which will only succeed if the result is a <bogus> element. What the user 
actually wrote was testing the result 
of the self::bogus expression (an empty sequence) against an empty sequence, 
which of course is always true.

It's hard to know what to do to avoid users making this mistake, given that the 
current behaviour (if the result 
of the test isn't a boolean value, you are testing the result of that 
expression) is really useful. Perhaps if the 
result of the test isn't a boolean, there ought to be a requirement for the 
select attribute and/or content of 
<x:expect> to be present.

Original comment by jeni.ten...@gmail.com on 1 Apr 2009 at 8:42

GoogleCodeExporter commented 9 years ago 
  It seems the problem comes from the duality of @test. It is
used either as a complete predicate test, or as a expression on
the result value to select the item to be compared as if there
where no @test.

  I think the ideal situation would be to have, either a @test
with a complete predicate (must return one boolean), or either a
@value to select a value to compare the result to or a content on
the expect element for the same purpose, and in the last case
(@value or content) the ability to have @select to select the
exact item to compare from the result:

    <!-- case 1 -->
    <x:expect test="count(...) eq 2"/>

    <!-- case 2 -->
    <x:expect value="'value'"/>

    <!-- case 3 -->
    <x:expect value="'value'" select="string(.)"/>

    <!-- case 4 -->
    <x:expect>
       <result/>
    </x:expect>

    <!-- case 5 -->
    <x:expect select="elem/result">
       <result id="..."/>
    </x:expect>

  Unfortunately @select is already used for the purpose of the
above @value, and @test is used for the purpose of both the above
@test and @select.

  Perhaps we should restrict @test to a predicate expression and
define a new attribute for the above @select (selecting an item
out of the result).  But here I cannot find a good name, except
@select ;-)

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/

Original comment by fgeorges on 7 Jan 2010 at 12:07

GoogleCodeExporter commented 9 years ago

Original comment by fgeorges on 25 Jan 2010 at 3:57

GoogleCodeExporter commented 9 years ago

Original comment by fgeorges on 25 Jan 2010 at 3:58

GoogleCodeExporter commented 9 years ago

Original comment by fgeorges on 1 Feb 2010 at 11:25

GoogleCodeExporter commented 9 years ago 
Deferred to 0.3, to get time to reach a consensus (see 
http://groups.google.com/group/xspec-users/browse_frm/thread/2ff0982553cc0ff7).

Original comment by fgeorges on 7 Mar 2010 at 5:58

GoogleCodeExporter commented 9 years ago

Original comment by fgeorges on 11 Sep 2011 at 6:28