Re: [xml-dev] Testing XML don't use xUnit

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Wed, Apr 10, 2013 at 10:54 PM, Liam R E Quin <liam@w3.org> wrote:
> On Wed, 2013-04-10 at 19:19 +0100, Ihe Onwuka wrote:
> [...]
>> > every $t in //table satisfies ($t/thead and $t/tfoot)
> [...]
>> a) it's still an absolute path
>
> in XPath, //foo is equivalent to "foo anywhere in the document" so it is
> not an absolute path of the non-robust sort.
>

If all the XPaths you are ever going to write for your test cases were
going to be //foo this conversation would not be necessary.

However paths of /foo/bar/baz[1]/abc[. > 10]  is far more
characteristic of the XPaths I have seen.

>>> b) Just for the  sake of argument I'll assume  that it mitigates the
>> problem - is it  practicable to expect or enforce that style of usage.
>
> You can't enforce intelligence. If your staff write bad tests, hire new
> staff. Changing tool-sets won't help with that.
>

It's got nothing to do with intelligence. If you go back to the start
of the thread I mentioned keyword driven testing is the phrase the QA
community came up with to describe how they deal with this problem.
It's exactly the same issue. They abstract away the path to the test
and they did it because that was the bit that kept failing.

One method is declarative and will never  suffer this problem. The
other method is procedural and is vulnerable to it.

One method is prone to over-engineering the other is not.

If Joe Bloggs and  everybody Joe Blogg's organisation hires  is
skilful and thoughtful enough to be able to write robust test
assertions then XMLUnit has otherwise has alot of nice things going
for it, but if your test XPath's look like

 /foo/bar/baz[1]/abc[. > 10]

(and that is not mutually exclusive from the predicate logic variant)
-  test code like that has this vulnerability.