views:

770

answers:

2

The xpath of my elements are becoming extremely hard to read.

//div[@id='main_content']/div[2]/div[2]/div[2]/div[4]/table/tbody/tr[2]/td/form/fieldset/p[1]/input

It would be nice if I could store most of that as a variable and use it later like this:

| assertElementPresent | ${myForm} . /fieldset/p[1]/input |

Is something like this possible? It would make my tests so much easier to read!

+3  A: 

You really should anchor your selenium espressions in ID's of elements instead. In 2 months, no-one is going to have the faintest idea of what the xpath points to, especially if the test is broken at the time you need to find out. We routinely add id's to element just to make testing easier. We've learned to accept that we write java code in a special way to make it testable, and I think it's ok for HTML too.

krosenvold
I totally agree with you. The example I gave probably wasn't the best to show why I'm trying to accomplish this. The reason I'm trying to do this is because the element IDs are randomly generated, so I don't know what they are.
Andrew
Well you can anchor further down in the dom structure, or make som id's you know about
krosenvold
If the id's are coming out of business data you can add positional id's somewhere nearby
krosenvold
A: 

You could just write:

store | //div[@id='main_content']/div[2]/div[2]/div[2]/div[4]/table/tbody/tr[2]/td/form | myForm
assertElementPresent | xpath=${myForm}/fieldset/p[1]/input

As Krosenvold said, however, long xpaths can be pretty fragile. If your concerned about readability in your code, and want all your locators in one file where you can make cascading changes, you might want to consider using an UI-Element map.

Peterl86