Absolute vs relative XPath in Selenium Java - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Absolute XPath

Which statement best describes an absolute XPath in Selenium?

A It starts from the root node and specifies the full path to the element.

B It starts from any node and uses // to find elements anywhere in the document.

C It uses CSS selectors instead of XPath syntax.

D It only works with elements having unique IDs.

💡 Hint

Think about how the path starts in the document tree.

Absolute XPath always starts from the root node (html) and follows the full path down to the target element.

❓ Predict Output

intermediate

Output of XPath Locator Usage

Given the following HTML snippet:

<html>
  <body>
    <div>
      <span id="target">Hello</span>
    </div>
  </body>
</html>

What will the following Selenium Java code return?

WebElement element = driver.findElement(By.xpath("/html/body/div/span"));
String text = element.getText();
System.out.println(text);

A null

B NoSuchElementException

C Empty string

D Hello

💡 Hint

Check if the XPath matches the element exactly.

The absolute XPath matches the <span> element with text 'Hello', so getText() returns 'Hello'.

❓ assertion

advanced

Choosing the Correct XPath Assertion

You want to assert that an element located by relative XPath //button[@class='submit'] is visible on the page. Which assertion is best in Selenium Java?

A assertNull(driver.findElement(By.xpath("//button[@class='submit']")));

B assertEquals(driver.findElement(By.xpath("//button[@class='submit']")).getText(), "submit");

C assertTrue(driver.findElement(By.xpath("//button[@class='submit']")).isDisplayed());

D assertFalse(driver.findElement(By.xpath("//button[@class='submit']")).isEnabled());

💡 Hint

Visibility means the element is shown on the page.

Using isDisplayed() checks if the element is visible. The assertion confirms this is true.

🔧 Debug

advanced

Debugging an XPath Locator Issue

The following code throws a NoSuchElementException:

WebElement element = driver.findElement(By.xpath("/html/body/div/button"));

Given the HTML:

<html>
  <body>
    <div>
      <section>
        <button>Click</button>
      </section>
    </div>
  </body>
</html>

What is the main reason for the exception?

A The button element does not exist in the HTML.

B The XPath is absolute but misses the &lt;section&gt; node in the path.

C The XPath uses relative syntax but should be absolute.

D The driver is not initialized.

💡 Hint

Check the full path in the HTML structure.

The XPath misses the <section> node, so it does not match the button element, causing NoSuchElementException.

❓ framework

expert

Best Practice for XPath Usage in Test Frameworks

In a large Selenium Java test framework, which XPath usage practice improves test stability and maintenance the most?

A Use relative XPath with meaningful attributes and avoid absolute paths.

B Use absolute XPath for all elements to ensure exact location.

C Avoid XPath and use only CSS selectors everywhere.

D Use XPath with index positions like (//div)[3] to speed up tests.

💡 Hint

Think about what makes tests less fragile when UI changes.

Relative XPath with meaningful attributes is less likely to break when the page structure changes, improving stability and maintenance.

Practice

1. Which of the following best describes an absolute XPath?

easy

A. It uses CSS selectors to locate elements.

B. It starts anywhere in the document using // to find elements by attribute.

C. It starts from the root node and follows the full path to the element.

D. It only works with elements having unique IDs.

Solution

1. Step 1: Understand XPath types

   Absolute XPath always starts from the root node, indicated by a single slash (/), and follows the full path down to the target element.

2. Step 2: Compare with relative XPath

   Relative XPath starts with double slashes (//) and can start anywhere in the document, not necessarily from the root.

3. Final Answer:

   It starts from the root node and follows the full path to the element. -> Option C

4. Quick Check:

   Absolute XPath = full path from root [OK]

Hint: Absolute XPath starts with / from root, relative with // anywhere [OK]

Common Mistakes:

• Confusing absolute with relative XPath syntax
• Thinking relative XPath always starts from root
• Assuming absolute XPath uses //
• Believing XPath only works with unique IDs

2. Which of the following is a correct relative XPath syntax to find a button with text 'Submit'?

easy

A. //button[text()='Submit']

B. /html/body/button[text()='Submit']

C. button[text()='Submit']

D. //*[@id='Submit']

Solution

1. Step 1: Identify relative XPath syntax

   Relative XPath uses // to search anywhere in the document. The expression //button[text()='Submit'] finds any button element with exact text 'Submit'.

2. Step 2: Check other options

   /html/body/button[text()='Submit'] is absolute XPath, not relative. button[text()='Submit'] is invalid because it lacks // or /. //*[@id='Submit'] looks for an element with id='Submit', not text.

3. Final Answer:

   //button[text()='Submit'] -> Option A

4. Quick Check:

   Relative XPath uses // and matches element by text [OK]

Hint: Relative XPath starts with // and matches anywhere [OK]

Common Mistakes:

• Using single slash / for relative XPath
• Omitting // before element name
• Confusing attribute and text matching
• Using absolute path syntax for relative XPath

3. Given the HTML snippet:

<div>
  <ul>
    <li>Home</li>
    <li>About</li>
    <li>Contact</li>
  </ul>
</div>

What element does the XPath //ul/li[2] select?

medium

A. The second <li> element inside <ul>

B. The first <li> element inside <ul>

C. The <ul> element itself

D. No element, XPath is invalid

Solution

1. Step 1: Understand XPath expression

   //ul finds any <ul> element anywhere. li[2] selects the second <li> child of that <ul>.

2. Step 2: Identify the second <li> in the HTML

   The <li> elements are: 1) Home, 2) About, 3) Contact. So li[2] is <li>About</li>.

3. Final Answer:

   The second <li> element inside <ul> -> Option A

4. Quick Check:

   //ul/li[2] = second list item [OK]

Hint: li[n] selects nth child li under the matched parent [OK]

Common Mistakes:

• Confusing li[2] with the first li
• Thinking XPath selects ul element
• Assuming XPath is invalid syntax
• Mixing absolute and relative XPath concepts

4. You wrote this XPath to find a login button:
/html/body/div/button[@id='loginBtn']
But your test fails when the page structure changes slightly. What is the best fix?

medium

A. Add more parent nodes to the XPath

B. Keep the same XPath; the failure is unrelated

C. Use CSS selector instead of XPath

D. Change to relative XPath: //button[@id='loginBtn']

Solution

1. Step 1: Analyze the problem with absolute XPath

   Absolute XPath starts from root and depends on full path. If page structure changes, the path breaks and test fails.

2. Step 2: Use relative XPath for stability

   Relative XPath like //button[@id='loginBtn'] finds the button anywhere by id, making tests more stable and maintainable.

3. Final Answer:

   Change to relative XPath: //button[@id='loginBtn'] -> Option D

4. Quick Check:

   Relative XPath is more stable than absolute [OK]

Hint: Use // and attributes for stable locators, not full paths [OK]

Common Mistakes:

• Adding more parents makes XPath fragile
• Ignoring XPath type causes flaky tests
• Assuming CSS selector always better
• Not updating XPath after page changes

5. You want to locate an input field inside a form, but the form's position in the page changes often. Which XPath is best to locate the input with name='email' reliably?

hard

A. /html/body/div[2]/form/input[@name='email']

B. //form//input[@name='email']

C. /form/input[@name='email']

D. //input[@id='emailField']

Solution

1. Step 1: Evaluate absolute XPath option

   /html/body/div[2]/form/input[@name='email'] is absolute and depends on exact page structure, which changes often, so it's fragile.

2. Step 2: Evaluate relative XPath options

   //form//input[@name='email'] finds input with name='email' anywhere inside any form, making it flexible and stable despite page changes. /form/input[@name='email'] is invalid because it starts from root but form is not root. //input[@id='emailField'] depends on id which may not exist or be different.

3. Final Answer:

   //form//input[@name='email'] -> Option B

4. Quick Check:

   Relative XPath with attributes inside form is best [OK]

Hint: Use //form//input[@name='email'] for flexible, stable locating [OK]

Common Mistakes:

• Using absolute XPath that breaks on layout changes
• Assuming input has id when it may not
• Starting XPath from root incorrectly
• Not using // to search anywhere inside form