{"id":3374,"date":"2016-01-05T01:04:00","date_gmt":"2016-01-05T06:04:00","guid":{"rendered":"http:\/\/qxf2.com\/blog\/?p=3374"},"modified":"2017-07-06T14:40:50","modified_gmt":"2017-07-06T18:40:50","slug":"getting-started-with-xpaths","status":"publish","type":"post","link":"https:\/\/qxf2.com\/blog\/getting-started-with-xpaths\/","title":{"rendered":"Getting started with XPaths"},"content":{"rendered":"

Assuming you already know what you want to automate and that you have a good reason to automate it, then GUI automation is largely about:
\na) identifying a web element you want to interact with
\nb) performing an action on the identified element
\nc) repeat steps a),b) until you have automated the workflow that you identified.<\/p>\n

To perform step a), all GUI automation tools use locators. A locator effectively tells your automation to look for “a big blue button with the label Confirm on it” or “a table cell with the word Qxf2 in it”. For web applications, XPaths <\/a>and CSS <\/a> selectors are used to locate web elements. This post helps you get started with writing good XPaths.<\/p>\n

XPath is used to locate a web element based on its XML(Extensible Markup Language) path. XPaths can be created in two ways: Absolute XPath and Relative XPath. Absolute XPaths are very susceptible to changes in the web page whereas Relative XPaths can be made more robust.This post focuses on Relative Path, henceforth every instance of XPath here would mean only Relative paths.<\/p>\n

\n

Why this post?<\/h3>\n

The foundation to robust GUI automated checks is writing good element locators. While talking to testers, we noticed that their habits around writing element locators have not evolved since they first learnt how to write them. Most testers just learn to write locators one way when they start learning GUI automation and then stick to it. Many bad habits that may be ok when getting started, persist through the tester’s career. So we thought we would write a series of posts to help you build good fundamentals for identifying elements for your GUI automation.<\/p>\n

\n

XPath structure<\/h3>\n

An XPath:
\na) starts with a \/\/
\nb) is followed by a HTML element
\nc) the HTML element is identified by a condition within square brackets
\nc1) the condition involves the attribute(s) of the HTML element
\nc2) the attribute is referenced by the @ symbol
\nc3) the condition can have logical operators like NOT, AND, OR, contains, =, etc.<\/p>\n

\"Constructing<\/a><\/p>\n

Constructing a good XPath involves finding a html-element, locating it uniquely based on its attributes and then if needed, deriving a path referencing it to another element which is less likely to change in a web page. We have tackled this more advanced version in this post<\/a>.<\/p>\n

\n

Examples<\/h3>\n

We are going to use the elements in the page http:\/\/qxf2.com\/selenium-tutorial-main<\/a> to clearly explain arriving at good XPaths. Let us try and create Xpaths for:
\nExample 1. the name field <\/strong> in the form
\nExample 2. the submit button in the form with text Click me!<\/strong>
\nExample 3. the cell with text michael@example.com<\/strong> in the Example Table. <\/p>\n

Example 1.
\nOpen the page with firefox or chrome, right click on the name field<\/strong> in the form and select Inspect Element<\/strong>
\n\"xpath_blog_namefield\"<\/a><\/p>\n

Note<\/strong>: We have tried arriving on an XPath from the basic syntax \/\/html element[@attribute = ‘value’]<\/strong> adding element,attribute and value with each step<\/p>\n

the first step in writing an XPath is identifying the html element ,input<\/strong> with unique attributes represent the element in the web page,<\/p>\n

\/\/input[@attribute = 'value']<\/pre>\n
in the next step an attribute is chosen for the html element,the  id <\/strong> attribute is chosen for this example as it is unique<\/p>\n
 \/\/input[@id = 'value']<\/pre>\n
in the final step we add the value ‘name’ to its attribute(id)<\/p>\n
 \/\/input[@id = \u2018name\u2019]<\/pre>\n
thus writing an XPath for the name field in this page is straightforward as it is represented by a html element with unique attributes. <\/p>\n
Excample 2.
\nTo inspect click me!<\/strong> right click on it and select Inspect Element<\/strong>
\n\"xpath_blog_clickme\"<\/a><\/p>\n
The html element for this example is  button <\/strong><\/p>\n
\/\/button[@attribute = 'value']<\/pre>\n
the attributes for the button element are class and type, we will use a different attribute for this example as we assume the  values of class and type may change<\/p>\n
 \/\/button[contains(text(),'value')]<\/pre>\n
The value for the attribute text() can be a phrase that is used to represent the element<\/p>\n
 \/\/button[contains(text(),'Click me!')]<\/pre>\n
Contains() operator  can be used if a particular text is unlikely to be changed,the name of the button is going to remain ‘Click me!’<\/p>\n
Example 3.
\n To inspect michael@example.com<\/strong> right click on it and select Inspect Element<\/strong><\/p>\n
\"xpath_blog_td\"<\/a><\/p>\n
The html-element for this example can be the table<\/strong> as its name attribute seems fixed.<\/p>\n
\"xpath_blog_table\"<\/a><\/p>\n
unlike the other two examples the XPath for this element has to be derived from a html element above it as the element that holds michael@example.com<\/strong> has no unique attributes.<\/p>\n
the closest html element is table<\/strong><\/p>\n
\/\/table[@attribute = 'value']<\/pre>\n
the attributes of the html element are class and name, like the previous examples we have chosen an attribute that is unlikely to change<\/p>\n
 \/\/table[@name = 'value']<\/pre>\n
the value of the name attribute is \u2018Example Table\u2019<\/p>\n
 \/\/table[@name = \u2018Example Table\u2019]<\/pre>\n
with the html-element set and defined, the element can be arrived at in two different ways<\/p>\n
(a) \/\/table[@name = 'Example Table']\/tbody\/tr[1]\/td[2]<\/pre>\n
(b) \/\/table[@name = 'Example Table']\/descendant::td[contains(text(),'michael@example.com')]<\/pre>\n
the XPath in example (a) is derived from the table html element to the corresponding element using indices whereas the XPath in example (b) we use the descendant (XPath axis<\/a>)to navigate to the element.
\nthough the examples a and b would find the intended elements, the example (a) is usually not preferred since the chances of re-ordering the data in the table are high ,i.e any other element could take the place of michael@example.com and it could be pushed to a newer location . The descendant  is used to make our locator robust to any changes that can be made to data in the rows of the table.<\/p>\n
\n
Tools:<\/h3>\n
You can check if the XPath you constructed identifies the element you want or not by using a couple of useful tools.<\/p>\n
1. Firebug<\/strong>– Firebug<\/a> is a Firefox plugin. Firebug provides access to a plethora of developer tools that supports editing, debugging and monitoring CSS, HTML and JavaScript live on any webpage. It assists in writing XPaths as it supports inspecting and editing HTML attributes and their values. For additional information on Firebug please refer Using Firebug 2.0 to craft XPaths<\/a><\/p>\n
2. CSS and XPath checker<\/strong>–  CSS and XPath checker<\/a> is add-on for Chrome to help you verify your XPaths.
\n\"CSS<\/a><\/p>\n
\n
Hope this helps get you started with XPaths. <\/p>\n","protected":false},"excerpt":{"rendered":"
Assuming you already know what you want to automate and that you have a good reason to automate it, then GUI automation is largely about: a) identifying a web element you want to interact with b) performing an action on the identified element c) repeat steps a),b) until you have automated the workflow that you identified. To perform step a), […]<\/p>\n","protected":false},"author":9,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[45],"tags":[],"class_list":["post-3374","post","type-post","status-publish","format-standard","hentry","category-xpath"],"_links":{"self":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/3374","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/comments?post=3374"}],"version-history":[{"count":66,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/3374\/revisions"}],"predecessor-version":[{"id":6379,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/posts\/3374\/revisions\/6379"}],"wp:attachment":[{"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/media?parent=3374"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/categories?post=3374"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qxf2.com\/blog\/wp-json\/wp\/v2\/tags?post=3374"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}