Here is the button I am attempting to click on
Log out
Here is what I have tried
driver.findElement(By.xpath("//a[contains(#class,'menu-linkRow')]")).click();
driver.findElement(By.xpath("//a[#href='/logout/?t=1550846736%2C09865a11c32ef819fb524c408c8f36cc']")).click();
You can try,
driver.findElement(by.linkText("Log out")).click();
It would be clear if give more details, like the exception you are getting and more!
Cheers!
Usually locating elements by xpath is a bad idea.
Try other approaches such as:
Locating by CSS Selector (should be your FIRST approach everytime) (This little guide will help you understand them). This includes the ability to specify patterns on element attributes such as:
[attribute~=value] [title~=flower] Selects all elements with a title attribute containing the word "flower"
Locating by any other strategy EXCEPT xpath
Locating by xpath as the very last resort.
Locating by xpath is considered an expensive operation and is extremely difficult to mantain.
You can also use whatever strategy you like but getting a collection of elements and later filtering them out by means of your favourite programming technique (i.e using Java8 Streams api), o just running another element search inside your elements such as:
element.findBy...
I strongly recommend adopting css selectors, as they are being heavily used to add style to any modern web application. So if the developer managed to resolve styling with css selectors, you will also be able to.
driver.findElement(by.Css('a.menu-linkRow')).click();
Also your second sentence "//a[#href='/logout/?t=1550846736%2C09865a11c32ef819fb524c408c8f36cc']" is using a session based locator which will not work on another session.
There is not need to use text and xpath as will be slower than css.
Related
I am testing a web app using selenium and java. I've always avoided xpath like it was a disease. Unfortunately, I got stuck on a stubborn web element buried deep inside a table unfortunately with no id or class. I tried everything and even invited my great great grand parents but nay...nothing worked, except xpath...see below.
I tried: className, name, cssSelector e.t.c. with e.g.
driver.findElement(By.className("kujes")).click();
This is what worked.
driver.findElement(By.xpath("/html/body/div[7]/div[3]/div/div[2]/div[1]/div[2]/div/div/div/div/div[2]/div/div[1]/div/div/div[6]/div/div[2]/div[2]/div/table/tbody/tr[1]/td[3]")).click();
I do not want anything less than professional in my work.
So, my questions are is xpath reliable and a good practice?
Is it professional to use xpath?
driver.findElement(By.xpath("/html/body/div[7]/div[3]/div/div[2]/div[1]/div[2]/div/div/div/div/div[2]/div/div[1]/div/div/div[6]/div/div[2]/div[2]/div/table/tbody/tr[1]/td[3]")).click();
The above approach is very very bad practice.
Never use indexes in your xpath. It becomes very fragile and will break every single time even when there is a small change in the target application. Try to ask the developers to add ID to that object.
It depends on the cases. Ultimate goal is to find selector which is unique and never changing until big change happens.
First you can try with id or class name which are unique.
Then we can play with css selector to find,
Element with attribute, classname , id and combination.
Element which is child of another element,
Element which is next sibling of another element.
You are using absolute xpath, which is unreadable and changing one. Using absolute xpath is completely unprofessional.
driver.findElement(By.xpath("/html/body/div[7]/div[3]/div/div[2]/div[1]/div[2]/div/div/div/div/div[2]/div/div[1]/div/div/div[6]/div/div[2]/div[2]/div/table/tbody/tr[1]/td[3]")).click()
You can use relative xpath
driver.findElement(By.xpath("//table[#id='somevalue']//td[text() = 'Name']]/preceding-sibling::td")).click()
There are few cases which are possible only with XPath in selenium
Finding parent element of an element
Finding preceding sibling of an element
Finding an element with innerText
Finding nth element of the locator
The above cases are not possible with css selector and xpath is the only straight forward way to find those element.You can also achieve these indirectly with jquery selector and javascript executor.
I am currently working on the Robot Framework and using Selenium2Libraries to work on a Web Application. I'm working on a Form and I'm dealing with a dynamic elements which is an editable text area and drop down list..
I really hope someone would be able to guide me on how I can do this. An example of what I am doing is,
[Example element code]
input id="textfield-1237-inputEl" class="x-form-field x-form-text x-form-text-default x-form-focus x-field-form-focus x-field-default-form-focus"
data-ref="inputEl" size="1" name="textfield-1237-inputEl"
maxlength="200" role="textbox" aria-hidden="false" aria-disabled="false"
aria-readonly="false" aria-invalid="false" aria-required="false" autocomplete="off" data-componentid="textfield-1237" type="text"
Any information on this would be much appreciated. Thanks!
There are many types of Identifiers are available.you can search,If the values are dynamic you can use Xpath Identifier to find the locator.Id can be used only for the static values.
In the above case you can use Xpath as
xpath=.//*[contains(type(),'text')]
because text is static.It wont be change.
When trying to handle dynamic IDs, and elements which dont have easy UIDs about them, the best way to go around this is using Xpath.
Xpaths are basically the location of the element within the HTML. This is kind of the best way to get around the problem of not having ID readily available (My work has no IDs anywhere I can use, thus I have no choice but to use Xpaths)
Xpaths are really powerful, if used correctly. If not they are really brittle and can be a nightmare to maintain. Ill give you an example of potential Xpaths you may have to use:
Select From List By Label xpath=(//select)[2] DropDownItem1
You said that you have a drop down. Here is a potenital "look-a-like" you would see. The Xpath here is basically saying, find the 2nd drop down you find, anywhere on the entire HTML page.
Xpaths will take a while to get your head round, esspecially if you have had the luxurary of using IDs. The tools I use in order to locate and debug Xpaths are:
FireBug
Selenium IDE
I mainly use Selenium IDE now, as it is a nice tool which basically lets you "Select" an element within the HTML and it will spurt out its ID, CSS Path, Xpath, DOM, etc... Not only that, when you come to discover more complex Xpaths, there is a "Find" tools which shows you visually, where your Xpath is pointing to (or isnt, if its wrong)
Something which really helped me was This. It is really usful and has a lot of examples for you to work against.
If you have any problems, just reply and ill try to help
More Examples:
Click Element //span[contains(text(), 'Submit')]
Input Text xpath=(//textarea)[3] Some Random Text!
As with the other answers, I propose that you use Xpath.
Using Xpath can point you to the element by identifying the relationship of that element with the other elements around it. So my suggestion is to find a static element that you could use as your starting point.
For example:
starting point has static id:
xpath=//td[#id='startingPoint']/following-sibling::select[1]
starting point has no id but has static text (usually the label of the field):
xpath=//td[contains(text(),'Field Label')]/following-sibling::select[1]
If you could give us an idea of what the element is..we could provide you better examples..
What I did was alter the Xpath for example:
//*[#id="cec9efb093e14182b361766c26fd1919"]/section/div[1]/ticket/div/div/input
And took out the Id what was being generated dynamically cec9efb093e14182b361766c26fd1919 to switch for an autoId I set to the parent element where the Id was being generated. It's a cheap fix but it works if only one of the parent element is being generated.
So the parent element has the attribute autoid=container added to it and I referenced it as [#autoid="container"]/section/div[1]/ticket/div/div/input in the robot code
The application which I'm testing is fast developing, and new features keep being adding, requiring changes to the testing XPaths. So the selenium scripts which were successful before now failed as the XPaths have changed. Is there any reliable way to locate element (which will never change)? FYI, I thought of using ID's but my application does not have ID's for each and every element as it is not recommended to give ID's in the code.
I feel the following is the hierarchy for choosing the element in selenium
1.id
2.class name
3.name
4.css
5.xpath
6.link text
7.Partial link text
8.tag name
In case of changing DOM structure you can try using functions like text() and contains(). The following link explains basic of the mentioned function.
http://www.guru99.com/using-contains-sbiling-ancestor-to-find-element-in-selenium.html
The following link can be referred for Writing reliable locators
https://blog.mozilla.org/webqa/2013/09/26/writing-reliable-locators-for-selenium-and-webdriver-tests/
Hope this helps you.
If you cannot impose #id discipline on the interface that keeps changing, one alternative is to use CSS selectors.
Another alternative to write more robust XPath:
Be smart about using the descendent-or-self axis (//):
Rather than /some/long/and/brittle/path/uniquepart use //uniquepart or //uniquepart/further/path to bypass that which is likely to change.
Don't overspecify label matching.
Use case-insensitive contains(), and try to match critical parts of labels that are likely to remain invariant across interface changes.
One other way I can think if is that you can load your page elements in to DOM and use DOM element navigation. It is a good practice to have id on elements though. If you have to use the xpath way then it is a good practice to split the path to keep the common path separately and adding the leaf elements as needed. In a way change in xpath triggering the test to fail is a good indication of catching the changes.
In our current automation (using Selenium/WebDriver/Java), we use #FindBy very extensively. For example:
#FindBy(css="a[name='bcrumb']") protected List<WebElement> breadCrumbLinks;
#FindBy(id="skuError") protected WebElement skuError;
#FindBy(className="reducedPrice") protected List<WebElement> reducedPrice;
#FindBy(partialLinkText="Injinji RUN 2.0") protected WebElement playButton;
#FindBy(linkText="annual member refund") protected WebElement annualMemberRefund;
#FindBy(xpath="//li[#itemprop='price']") protected WebElement productPrice;
By definition, #FindBy can locate a selector using the following: using, id, name, className, css, tagName, linkText, partialLinkText and xpath.
Recently, our front-end devs proposed that we implement an new attribute class that begins with 'test='. I think this is a great idea since we could find WebElements by just looking for that blurb of text, rather than the values that #FindBy inherently uses. My question is, would it be better to extend the existing functionality of #FindBy OR, create a new way of searching for the WebElements we use in our tests?
First off, there are no "best practices," just ones that work well in your particular context. Sorry, that's an old gripe of mine...
I wouldn't spend the effort for custom attributes unless you can't work with an existing approach. I prefer using existing locators (find logic) where possible.
Whenever possible, use ID attributes. If the page is valid HTML, then IDs are unique on the page. They're extraordinarily fast for resolution in every browser, and the UI can change dramatically but your script will still locate the element.
Sometimes IDs aren't the right choice. Dynamically generated IDs are almost always the wrong choice when you're working with something like a grid control. You rely on an id that is likely tied to the specific row position and then you're screwed if your row changes.
In some of these cases your devs can help you out by appending or prepending constant values to a dynamically generated ID value. ASP.NET Webforms does crazy stuff with dynamically generated values, so I've used a suffix to my advantage several times.
Link text, name attribute values, and CSS selectors (JQuery style) are great second choices when you can't get a stable, reliable ID, or one's just not available.
XPath is my last choice in nearly all situations. It's slow, can be extremely brittle, and is hard to deal with when it's a complex XPath. That said, if you need to move up and down the page DOM for your locators, then it's the only choice.
Using one of the existing FindBy methods means you'll be using a well-understood, well-supported locator strategy. That's a big bonus when you're trying to figure out an old test, or when onboarding someone new to your team.
That's my $0.02.
I think this will help Selenium Locators Best Practices
Tastiest Locators:
ID
Name
Class
Link
Text or Partial Text
Yummy Locators
Index
XPath
Child Elements
CSS Properties
Edible Locators
JS Events
DOM Elements
KeyStrokes
Coordinates
If I understood you correctly you can continue using #FindBy annotation with css selectors such as css = "[test='...']".
selenium.click("gwt-uid-204"); // this is recorded from Selenium IDE
I am clicking the check box in my (gwt) java application. The gwt-uid is changing ever time, so if the id changed then my element is not found in my apps. The regular expression is not working for me and I am not sure what I am doing wrong. Thanks for your help
selenium.click("gwt-uid-[0-9]);
I am using selenium 1.0.3, Java
Many GWT elements comes with ensureDebugId (method on UIObject) to allow you to explicitly set Ids to elements for testing and debugging purpose. You also need to inherit the module
<inherits name="com.google.gwt.user.Debug"/>
to make it work. The advantage of this is, you can remove the trace from the production deployment by removing the inherited module in during prod mode compile. Hence there wont be code changes to remove unnecessary Ids.
You can do it in 3/4 ways
Can check this link :
3 ways of dealing with GWT dynamic element Ids
which talks about 3 different ways of assigning a static id to your GWT elements.
Also,
You can write a custom javascript method which will fetch all the ids dynamically. Then you can process those ids for selenium actions.
There are two possible solutions. The first is to tell Se that you are using a regex by saying regex:gwt-uid-[0-9]. As you have it there it is looking the and element whose name or id is that literal string.
The other solution is to turn on static id's for things which I discuss in http://element34.ca/blog/google-web-toolkit-and-id.
-adam
Assuming you have dynamic IDs, as you have presented, first realize that Selenium's click method takes a locator argument. A simple approach is to specify a locator that finds an ID starting with your constant "gwt-uid-" prefix. You can use any of these locators as the argument to your click method, depending on your preference of technologies:
== XPath ==
//input[starts-with(#id, 'gwt-uid-')]
== CSS ==
css=input[id^='gwt-uid-']
== DOM ==
dom=for each (e in document.getElementsByTagName('input')) if (e.id && (e.id.substr(0, 'gwt-uid-'.length) === 'gwt-uid-')) e
Footnote 1: I have not used GWT, so my examples above assume that it still puts a check box in an <input> element; adjust as needed.
Footnote 2: Selenium does offer regular expression support, as Adam intimated, but there are two issues with it in this case: (1) the prefix is "regexp:" rather than "regex:". (2) Selenium's click method does not support the regexp prefix at all! (My empirical evidence suggests that locators do not use regular expressions in Selenium, only text matching arguments do.)
You can also use Firebug add ons to remove the GWT UID.
Right click where the GWT UID is and select "inspect element with
firebug" -
Click on the code where the GWT UID is and when the firebug windows
appears select "deleted attributes id"
After removing the id, right click one more time and copy the "Xpath"
Add an extra (/) and paste the xpath on the target.
This may also help.