Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Wed, Apr 10, 2013 at 10:54 PM, Liam R E Quin <liam@w...> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
