-1

Is it a good practice to make all the xpaths in the script Data Driven? I mean to fetch the all xpaths from excel and not to keep any xpaths in script and if any changes occur in xpath, we just need to make changes to xpath in excel and not in script.

Ashwiinn Karaangutkar
  • 161
  • 3
  • 4
  • 13

4 Answers4

0

I typically load my xpath in from a properties file (or ini file if using C#). You could use xml or json though too I suppose.

Haven't thought about using excel, but I suspect there might be some initial performance drops when that file gets loaded.

aholt
  • 2,829
  • 2
  • 10
  • 13
0

We did this in our project. We had an XML (not Excel) and data driven tests just looped and tested the application.
One of the motivations for this solution was that on the long run the manual QA guys would update the XML file while the automation developers would handle the framework.
Worked like a charm.

user3734429
  • 322
  • 1
  • 10
0

Absolutely its a Good Practice, because if some Locater gets change you will have to walk through the whole Test-code to adjust the Locater's wherever necessary which is bit more difficult then traversing through Excel file. Also its makes your Test-code non-brittle, Reduces the dependencies between test-code and definitely improves readability.

Rupesh Shinde
  • 1,933
  • 12
  • 22
0

Data driven is definitely the way to go prevent test suite from becoming to brittle but I agree you don't need to use excel there are numerous ways to handle this. For instance you could also just create a dictionary in the test suite and reference all the xpaths from there. Here's a python example:

locators['homepage.add_class'] = '//*[@id="contentmain"]/div/div[2]/div/div/h3'
locators['navigator.logout']   = '//*[@id="flyout-navigation"]/div[3]/div/div'
locators['login.failed']       = '//*[@id="main-alerts"]/div/div/div'
...
nonzero
  • 31
  • 5