How to use values of properties file in selenium code

[mahender tester]

Hello ,

          I'm new to selenium . I organised all my web element Xpaths  in a file '' OR.properties"  file and i want them to use in my slenium code . How can i do this .Please send me sample code to this .

Thanks In advacnce.

[Syed Sayem]

Personally, I don't think it's good practise, but if you want to use it, here's an example!! 

driver.findElement(By.xpath( OR.getProperty("emailAddress"))) .sendKeys("em...@email.com");

driver.findElement(By.xpath( OR.getProperty("password"))) .sendKeys("passw@rd"); 

driver.findElement(By.cssSelector(OR.getProperty("loginButton"))).click();

https://github.com/sayems/WebDriver/blob/master/src/main/java/com/sayem/readingproperties/Reading_Properties.java 

[akki]

Hey Syed, I was also considering the same approach to store my locators. Would you please elaborate on why it is not a good approach and which is a better approach.

[David]

I think there is debate on the topic of whether it is good or bad, though the general consensus is to stay away from it. Personally, I think it really depends on how you structure & manage your test data & code which determines whether this will be useful to you or not.

I personally would advocate it. I consider locators as a form of test data (though not of the same type as input data used to say type into text fields, etc.). If you look at it that way, then it is better to abstract it out of the test code and treated as a "config" or properties and used similarly to data driven testing of being fetched from external source. Is also useful for changing locators w/o having to recompile the Java test code. But doing it this way, you loose integration of locators being matched up with the test code/flow, in case that is needed, particularly say if combined with page objects.

And if you do use property files for locators, it becomes more useful if you abstract out the locatory type from code, so instead of

driver.findElement(By.cssSelector(OR.getProperty("loginButton"))).click();

you have something like this

driver.findElement(myUtilityClass.parseLocator(OR.getProperty("loginButton"))).click();

where myUtilityClass.parseLocator() is a custom class method you write that will figure out the locator type from what you pass into it and return appropriate By object. The figure out coudl be like matching against locator prefix for Selenium RC style locators, in which case your property file would contain something like this

loginButton=css=someCssSelectorValue

emailAddress=xpath=someXpathValue

password=id=someIdValue

though of course I haven't done this myself, but that's how you would do it in theory, so calling OR.getProperty("loginButton") would return "css=someCssSelectorValue"

this approach also helps if you're migrating over from Selenium RC, so can keep RC locators intact, if they still work in WebDriver w/o modification of the values.

[Mark Collin]

I think a long list of locators hidden away in a property file is insane, you end up with long unreadable lists of rubbish.  It may well look manageable at first but eventually it gets really long and anybody new looking at the codebase has to sit there for hours trying to work out where everything links together.  Secondly if you have a long list of locators hidden away in a properties file and you want to change the name of one of these properties you have refactoring hell (If you are using a decent modern IDE like IntelliJ IDEA you can change the name of a variable in one place and it will change that name everywhere else for you).  Keep it in the code is my recommendation.

 

What you should really do is use page objects.  Page objects can be for a whole page, or you could split out a consistent bit of functionality into its own page object (for example if you have a header and menu bar that is consistent across the whole site split it out into its own page object and reuse it in your other page objects).

 

At the end of the day there are many ways you can structure your data, but try and do something that makes it maintainable in the future and easy for new people who join the project to understand.

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to seleniu...@googlegroups.com.
To unsubscribe from this group, send email to selenium-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/selenium-users/-/VZdgWKWVaWIJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David]

Great points Mark, thanks. That will be a good reasoning of disadvantages to the approach.

Also wanted to point out though that going properties file approach, one doesn't have to lump all locators in a single properties file. You could split it up architecturally as you see fit. Same as whether you lump all Selenium code in a single class file or break it up w/ OOP and/or page objects.

And on topic of page objects, at least from my collaborations, you can group locators for page together with the page methods/actions or split them up into separate files (there's no set in stone standard like with agile). And if you chose to keep them separate in the page object design, you can then also implement with properties files with one property file mapped to each page object.