[ptt-users] TestMaker: "Error getting page String index out of range"

[Lars Huttar]

Thank you, Olivier, for your very helpful and informative reply to my 
somewhat frustrated email. :-)
That should get me a lot further down the road.

Lars

On 9/28/2007 2:26 AM, Olivier Dony wrote:
> On Sep 27, 2007, at 10:47 PM, Lars Huttar wrote:
>
>> What I'm trying to get to work right now is this.
>> I have a TestGen4Web unit test with the following action:
>>        <action type="click" refresh="true" step="2">
>>            
>> <xpath><![CDATA[*/a[@href="proof/summary-by-continent"]]]></xpath>
>>            <value><![CDATA[]]></value>
>>        </action>
>>
>> When the test runs, I get the following output in Local TestNode Output:
>>> Step  2: (click)
>>>     Executing: click
>>> Error getting page String index out of range: -5
>>> Got page: Ethnologue Publishing Home [which is the old page, not the 
>>> page I'm clicking on the link for]
>> So somehow, this action is failing because, as it seems, the 
>> [@href="..."] predicate is failing via a string index out of range.
>
> It seems you've run into a TestMaker bug. This occurs when the 
> TestMaker engine attempts to convert the "pseudo-XPath" from 
> TestGen4Web into the real XPath needed by the test engine. This fails 
> because you predicate contains a forward slash character '/', and 
> TestMaker is splitting the expression on '/' to analyze the XPath.
> So it tries to handle separately */a[@href="proof and then 
> summary-by-continent"], which leads to the exception you've seen.
>
> If any of the developers read this thread, thank you for creating a 
> bug report for this.
>
> Maybe you can work around this issue by using "positional" XPath to 
> find the element in the page structure.
> For example:   */FORM[2]/P[1]/A[4]
>
> As a general rule, your life will be much more easier with TestMaker + 
> TestGen4Web (and other test tools) if you can have a unique ID 
> attribute on all elements you need to use in your tests: links, form 
> fields, buttons, etc.
>
>
>> Initially when I generated the unit test using TestGen4Web, the 
>> <xpath> was:
>>            <xpath><![CDATA[*/A[@CDATA="Summary by
>>        area"]]]></xpath>
>> which resulted in the output
>>>     Executing: click
>>> oldXpath  */A[@CDATA="Summary byarea"]: newXpath 
>>> "//a[string()="Summary byarea"]"
>>> Elem null
>>> Error getting page null
>>
>> So it looked like that was failing because the CDATA containing a 
>> carriage return was not working as a selector.
>> That's why I changed the predicate to use [@href="..."].
>
> You're right, and this is another annoying issue. TestMaker converts 
> this pseudo-predicate "@cdata" into "@string()=", but this does not 
> work well with link label, due to different whitespace issues. Maybe 
> if something like contains() was used to construct the real XPath it 
> would work more often.
>
>
>> The "String index out of range" messages seems to be a Python error.
>
> It is actually the Java exception message occuring within 
> com.pushtotest.testmaker.XSTest.client.TestGenForWeb.normalizeXPath() 
> when it tries to convert the pseudo-XPath.
>
>
>> I'm wondering whether this <xpath> stuff is really XPath, or just a 
>> semblance thereof. I haven't been able to find reference 
>> documentation for it.
>> For example @CDATA doesn't seem to be real XPath, and then there's 
>> the question of whether HTML elements like A are case-sensitive.
>
> Exactly. The "XPath" locators from TG4W are not really XPath, which is 
> why TestMaker needs to do the conversion on-the-fly.
> I don't know if there is any documentation about this, but maybe this 
> will interest you:
>
>   http://cake.pushtotest.com/pipermail/users/2007-September/003415.html
>
>
>> I guess this is a TestGen4Web issue, but it seems to be obstructing 
>> use of TM, so maybe that makes it of concern to TM.
>>
>> Any help is appreciated.
>
> I hope this helps.
>