5

I am currently working on a building an automation testing framework using selenium+TestNG with over 1000 test cases. The test cases I am writing use a lot of elements and I was thinking is it a good approach to read the elements from an external file(Plan to do this as there are too many xpaths in the code file which makes it difficult to read the code).

I was thinking that xpaths can be written to an excel(or other external) file and can be populated to a HashMap during execution.

Is this a good approach or should I stick to writing xpaths in the code files?

5

My personal opinion is against it.

  • What difference does it make by storing all xpath in a seperate excel sheet? It does not make the number smaller.
  • Having an external file reduces maintainability, what happens someone loses tracks of it.
  • You introduce additional complexities to your code, additional codes being open the external file, read it and close it.
0
3

Your tests are code, locators are code. Please leave the locators near the code and use a version control system. Why would you want to add another dependency?

Research the Page Object model to centralize where the Xpath are stored, this is the current facto standard.

Reads:

1

Code of tests should not contain xPathes. But that is done with architecture of tests. Code of tests should be separated from code of low-level actions (interaction with browser elements):

enter image description here

In this example test methods are in classes GroupCreationTests, GroupDeletionTests and all low-level interaction in Helper classes.

1

Is this a good approach or should I stick to writing xpaths in the code files?

I think this is an excellent approach.
What you have described sounds exactly like a Page Object model.

My main reason for using a Page Object model is to do exactly that - remove the, often convoluted, css and xpaths from the test code and place them in a different spot. It also DRYs up repeated references but for me that is actually secondary after the good name itself.

It doesn't really matter whether the actual implementation is:

  • variables
  • static methods
  • hashes
  • .yaml files
  • dynamic methods

In fact in the software I currently work on Page Objects have gone through 4 of these variations and in all of them these definitions were stored in other files within the project hierarchy.

I would not choose a .xls format but a .csv files, one line per locator could work and would be editable. Really a simple text file would be best of all with the format being some sort of key-value pairing of name-locator.

0

As a general principle all of the locators, (whatever their nature), should ideally be automatically generated from the detailed design specification and then be imported into both the code and the test cases.

Above all do not think of using Excel for storing these as the process of reading things from excel is horrible and it doesn't version control well in many version control systems - either a plain text structure of pathid:xpath or better yet a json file containing them would be much easier to import, version control, etc.

As mentioned in another answer your version control system should be your friend here - use it and let it help you.

2
  • If most of the world wasn't doing Agile this ideal approach would work. However, over the past few years, surveys I have seen of thousands of companies have most doing Agile. No detailed up-front specs, you have to work with the team as development goes, which, yes is quite a challenge. – Michael Durrant Nov 14 '16 at 15:20
  • @MichaelDurrant - In agile your user stories are your mini-specifications and if your team has a consistent mechanism for capturing & exchanging them you can use that but excel is almost always a mistake in my opinion I was recently on a project that had an Interface control document in Excel which meant that the actual interface definitions were always separate and could get out of sync and also some sites were using an old version of office which caused a number of problems. – Steve Barnes Nov 14 '16 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.