Writing XPath selectors for Selenium tests

Tutorial: Writing XPath selectors for Selenium tests

Selenium is the most commonly used web testing framework. It allows you to write tests in Java that can perform standard “web” actions such as filling in forms, clicking buttons etc. Usually, a test will take the following form:

• Open a web page.
• Locate an html element.
• Interact with it in some way. i.e. click it, type into it, select an option
• Locate another html element.
• Interact with it.
• etc

Locating elements is obviously key to writing a test, and Selenium offers several ways you can do this:

• By name.
• By id.
• Using XPath.

Using the name or id is okay for simple tests, but for more complex situations, you need to know how to write XPath queries. Even though you will typically start off by using the Selenium IDE Firefox plugin to record a test, which will automatically generate selectors for you, in practice you will usually find that you need to change some of them. This will often happen when you are dealing with a web page that is dynamically generated. For example, suppose you are searching a website for a shirt to buy. If there are various sizes and colours available for the shirt, you could get back multiple “Add to bag” buttons. When you click the button for the white shirt in collar size regular, the Selenium IDE won’t know that this is what you are doing. It will do its best to write an expression that picks out the button, but it will probably be incorrect. For example, if the button you click is the second one on the page, the Selenium IDE could use that to pick out the button. However, if you rerun the test and some of the sizes or colours are out of stock, the button you want might not be the second one. What you really want to do is write a test that knows to “click the button for the white shirt in regular size”.  XPath allows you to do this, but XPath queries can be quite complex to begin with, so the purpose of this tutorial is to guide you through writing a query, step by step.

Example

Step 1 – Navigate to the problematic web page

The first step is to manually navigate to the web page which your test is having a problem with. I’ve recently been working on a test that purchases a product by selecting a customer, then a product, then entering address details, then finally credit card details. I used the Selenium IDE to record the test and then saved it as Java code for playback. However, when running, it failed at the stage of entering the credit card details, specifically the card number. Have a look at the following screenshot and see if you can tell why:

Did you spot it? There are two “card number” fields on the page. The recorded Selenium test was picking up the one for the gift card. You can see that we need the one in the credit card section, so how do we go about changing the selector to pick this out?

Step 2 – Write and test your XPath expression

There are a number of ways to write and test an XPath expression:

1. Using the Selenium IDE itself – it has a “test” option.
2. Using Firebug and a separate XPath tester.
3. Using Firebug and the FirePath tester, which is a separate add-on but integrates with Firebug.

All these methods work, but the third method is probably the most powerful, so it is the one I will explain here. The first thing to do is to identify the html element that you are interested in, and see how it fits into the structure of the page. If I open up Firebug, I’ll see something like this:

Firebug has the “selector” tool,  which allows you to select an html element on the page and see it in the HTML view. It is the arrow icon in the top left of the FireBug panel:

Once you have added the FirePath extension, you’ll get a separate FirePath view and you’ll also be able to use the selector tool to bring up an element in that view. So, if I switch to the FirePath view and then use the selector tool to pick out the card number input box, I’ll see the following:

An XPath expression that picks out the element will automatically be generated and displayed at the top of the panel. However, this is the expression that needs to be rewritten. I find the easiest way to write an XPath expression is to gradually build it up. What is the simplest thing to start with? Well, I’m looking for an input, so a good start might be to write something that will select all inputs:

//input

Sure enough, FirePath highlights all of the inputs on the page:

I know that I need the card number input within the “Credit Card” area of the page, but how do I know what XPath expression to write to pick this out? Well, you can use Firebug to inspect the DOM to understand the structure:

Looking at this structure, you can see that conceptually I’m looking for the input with the id of cardNumber that is within the div that has an h3 heading of “Credit Card”. To build up an expression for this, you can start by just trying to pick out that div. For example:

//div[h3/text()='Credit Card']

This correctly picks out the div, but how do you navigate down to the input? Well, in XPath you use axes to navigate up and down the DOM. The input is within the div, so we’ll need to use an axis like “child” or “descendant”. You could test that with:

//div[h3/text()='Credit Card']/descendant::*

Sure enough, that picks out all of the nodes beneath the div. I know that I want an input with an id of “cardNumber”, so I change that to:

//div[h3/text()='Credit Card']/descendant::input[@id='cardNumber']

This works, but actually it is overspecified. What if the heading was changed to an h2 or a legend? It is more flexible for the expression just to specify that the div must have some kind of child node with the text “Credit Card”, rather than specifically an h3 heading. Hence the final XPath expression is:

//div[*/text()='Credit Card']/descendant::input[@id='cardNumber']

Step 3 – put the XPath expression back into your test and rerun

Once you have worked out the XPath expression, you can put it back into your test and rerun it. I’m using the Selenium 2 API for my test, so the code becomes:

webDriver.findElement(
  By.xpath(
    "//div[*/text()='Credit Card']/descendant::input[@id='cardNumber']"
  )
).sendKeys("1234123412341234");

If you’re using Selenium 1, your syntax will be more like:

selenium.type(
  "//div[*/text()='Credit Card']/descendant::input[@id='cardNumber']",
  "1234123412341234"
);

---

Hopefully you’ll find that by using the above technique with Firebug and FirePath, you can build up and test even complex XPath expressions easily. If you want to read up on XPath, a good place is the w3schools tutorial:
http://www.w3schools.com/xpath/default.asp
Firebug can be downloaded from:
http://getfirebug.com/
and FirePath from:
https://addons.mozilla.org/en-us/firefox/addon/firepath/

Soure:

Hedley Proctor

Setting up TestNG with Eclipse

This post will explain about installation of TestNG plug-in with Eclipse (Indigo)
There is no need to download any Jar file or exe file for installation.  We need to just utilize the “Install New Software” option available in the Eclipse.
Steps for installation:
1. Click Help –> Install New Software



2. Type “http://beust.com/eclipse” in the “Work with” edit box and click ‘Add’ button
3. In the ‘Name’ column we can see “TestNG” –> Select this and click ‘Next’ button

4.  Click Next and click on the radio button “I accept the terms of the license agreement”
5. Click ‘Next’ button
6. Click ‘Finish’

This will install the TestNG plug-in for Eclipse
After the installation, it will ask for restart of Eclipse.  Then restart the Eclipse.
Once the Eclipse is restarted, we can see the TestNG icons & menu items as in the below figures.



It is very much clearly explained how to setup the TestNG with eclipse.  The screenshots make it easy to understand the setting up of TestNG. I hope this will help people who are eager to start using TestNG for their unit testing as well as UI Test Automation with Selenium.

Resource:  selftechy

Test Process

Test Process Definition

Our Test Process Consulting Services will define and implement software testing norms, processes, guidelines and templates through test process definition meetings with in-house process groups, and interviewing key software personnel. Our Approach consists of the following steps:

As is Analysis
PureTesting conducts a detailed analysis of the current processes and the methodology in use and compares the same with the best in class practices.

The information on the current state is collected from the following sources:

• Key Stakeholders and their expectations
• Process documentation
• Project documentation

This step is mandatory to obtain an objective view of the current process maturity. This approach involves studying the existing processes/ methodologies, identifying gaps, and providing recommendations to fill in these gaps. This is a collaborative exercise between PureTesting and the customer.

Process and Project documentation reviews
This is required to understand the current testing practices as defined and documented in the Customer Quality Management System, if any. This will enable in understanding the implementation of practices in projects. This will give an understanding of the process and process implementation culture and an in-depth understanding of the gaps in the processes/practices vis-a-vis the best in class processes and methodologies. This will also provide areas for improvement and highlight the current strengths. PureTesting consultants will ensure that existing practices are leveraged while defining new processes.

PureTesting consultants will present the As-Is findings along with gaps, opportunities of improvement and existing strengths to the Customer's Senior Management and relevant stakeholders. This will also cover the high level roadmap for process improvement and implementing the recommended changes.

Roadmap Plan
Based on the output generated from the analysis, a detailed roadmap plan is developed. A single plan in the form of a Microsoft Project plan (mpp) is generated detailing the activities, timelines and the responsibilities. This forms a basis for the entire program and provides an integrated approach and removes redundancy. The roadmap also enables customer to effectively deploy the project objectives into a set of actionable steps.

PureTesting Consultants will identify the risks, constraints and bottlenecks and other dependencies and prepare mitigation and contingency action plans for the same.

Process definition
A Single Software Test Life Cycle model and associated documentation (processes, procedures, templates, guidelines etc.,) shall be developed. Detailed tailoring guidelines will accompany this model to help practitioners to tailor the Software Test Life Cycle to suit the various types of projects being executed in the customer's organization.

Process change/ improvement or new process additions are initiated based on the recommendations of the AS-IS report. Adequate details are looked into such as the availability of expertise to review the process change, extent of process reuse to limit changes to minimal limits, prioritizing the process change requests, grouping of interfacing processes.

PureTesting consultants will conduct a process workshop to make the customer Senior Management and relevant stakeholders aware of the new/ improved processes. This will validate the processes and approval of customer senior management is obtained. This will also facilitate the process Train the trainers program for customer.

Process Implementation support
Process implementation support is provided in terms of process and tools trainings to the practitioners. Training material will be developed by PureTesting.

PureTesting consultants will verify the implementation through periodic audits and reviews and report the compliance to the customer's Senior Management.