[ptt-users] Xpath issue

[Lars Huttar]

On 9/28/2007 3:07 AM, Olivier Dony wrote:
> On Sep 27, 2007, at 11:41 AM, bl8cki wrote:
>
>> Really thanks for your quick answer.
>>
>> So if i understand you right ... when i make for example a new 
>> functional test in TestMaker and there i include a test
>> that was made with testgen4web i can use real xpath expressions.
>> I put in mytest.testgen4web something like this:
>>
>> <action type="click" step="4">
>>   <xpath><![CDATA[//a/span[text()="Name" and @class="name"]]]></xpath>
>>   <value><![CDATA[]]></value>
>> </action>
>>
>> and when i run this functional test with the mytest.testgen4web test 
>> case, i look at the
>> LocalTest Node Output and there i see:
>>
>> oldXpath  //a/span[text()="Name" and @class="name"]: newXpath 
>> "////span[text()="Name" and @class="name"]"
>> which is not valid (and the 'a' is gone) and because of this 
>> org.jaxen.XPathSyntaxException: Location path cannot end with //
>>
>> What can i do? And am i doing things right?
>
> Yes, this is what I meant, but apparently there is another issue here :-(
> When you change the XPath produced by TestGen4Web, it is still run 
> through the conversion layer of TestMaker, to make sure it is really 
> XPath.
Is there a way to have TM *not* run the test through the conversion layer?
Maybe by using a different type of unit test (i.e. not <tg4w>)?
Or not until a selenium test interpreter becomes available?
>
> This is done by TestGenForWeb.normalizeXPath(). You can have a look at 
> it if you're interested:
>    
> http://cvs.pushtotest.com/cgi-bin/cvsweb.cgi/tm5/TestMaker/src/com/pushtotest/testmaker/XSTest/client/TestGenForWeb.java?annotate=HEAD 
>
>
Looking at this code, it's surprisingly naive, for a product that claims 
to enable you to automatically generate test cases.
It's tempting to try and write a patch to improve the parsing, but I 
wonder if it's worth it... writing a parser is notoriously 
time-consuming, probably more so for a pseudo-language that seems to be 
undocumented.
Maybe a good approach would be to try to "normalize" the XPath after 
it's parsed by the Jaxen XPath parser (which is already used by this 
code, via Gargoyle's HtmlUnitXPath).
E.g. using BaseXPath.getRootExpr().
If the XPath parser can handle TG4W-XPath.

But maybe the time of TM users and developers would be better spent 
getting TM to work with a tool that produces real XPath, like Selenium.
> The converter doesn't care whether the expression is real XPath or 
> pseudo-XPath, and applies its algorithm anyway.
> So you can indeed modify the XPath produced by TG4W, but I guess you 
> need to make it look like pseudo-XPath.
>
> I hope this will be improved in the future, but if you need to make it 
> work right now you should be able to, by following a few rules, such as:
>   - use "*/" instead of "//" at the beginning of your XPath
>   - do not refer to elements without predicates,
>     e.g /a/ will be replaced by a single "/", while "/a[1]/" will be 
> preserved
>   - never use forward slash "/" characters within your predicates
>
> Thus you might have better luck with something like:
>       */a[true()]/span[text()="Name" and @class="name"]
>
>
> Cheers,
>
>
>
> -- 
> Olivier Dony,