Selenium Web Test Automation Framework Best Practices

David Burns is a smart guy. His book is a good starting point for anyone who wants to learn the basics of Selenium and test automation. Of course, take his (and mine, and everyone else's) advice with a grain of salt. There are lots of experts and lots of opposing opinions. You'll have to figure out what works best for you.

Yes. It is definitely a good idea to "keep all methods, verifiers of a particular page in a separate class." You could rephrase that as "separating action and intent" or "programming in the domain language". Either way, you want to avoid writing tests in low-level Selenese. One way of doing this is by using the Page Object test design pattern. Many of the contributors to Selenium and other selenium experts advocate using page objects. It is a good way to make test code more robust, readable and reusable.

Knowing other design patterns is useful too and using them in your test framework is probably a good idea. Unfortunately there is no single 'best' approach. You'll probably have to use multiple patterns and a blend of approaches to achieve good test code. I would recommend starting small, writing a few tests, noticing code smells and re-factoring. Your test framework will grow. You don't have to design it all up front. Be agile. Use an iterative, incremental approach. (Don't use the Selenium IDE)

youtube - Simon Stewart Talks about automated test patterns and Selenium

Rather than putting your test steps in a database table, it's probably better to use a testing tool like Junit or TestNG to organize your tests. TestNG has build in functionality for selectively re-runnning failed tests. It also has really good reporting capabilities. Don't reinvent the wheel here. Learn a testing framework like TestNG or Junit.

youtube TestNG

oh man... I can't post more than two links right now... Oh well... I recommend looking for GTAC videos on youtube, saucelabs videos on viddler, Simon Stewarts blog, the TestNG documentation, examples of page objects and a paper by Brett Pettichord called Seven Steps for Automation Success.

Good luck!

http://mestachs.wordpress.com/2012/08/13/selenium-best-practices/

• Use PageObjects pattern
• Be fluent with
  • return this, varargs, generics,
  • reuse your model and jodatime
• Be robust and portable
  • Prefered selector order : id > name > css > xpath
  • Avoid Thread.sleep prefer Wait or FluentWait
  • Use relative URLs
  • Don’t rely on specific Driver implementation
  • Create your dataset
• Know your new tool
  • Keep up to date (versions and usage pattern)
  • Troubleshooting
    • jre 1.6
    • IE (zoom, Protected mode setting )
    • Firefox/firebug startpage
  • How to deal with UI components like... fileupload, datepicker, ajaxtables,...
  • Detect when selenium isn't the good tool for the job
  • Don't be afraid to hack around selenium

I've written code testing frameworks under five different applications (WinRunner, LoadRunner, QuickTest Professional, TestComplete, Selenium WebDriver) and I've found a number of things have worked for me:

1. If a test suite is meant to be quick and mean, you don't need a framework. My first tests were largely framework-free.
2. When you get into a more complicated application, object repositories (for GUI applications) and Page Objects (for Selenium WebDriver) make work more effective.
3. I tend to spend my time working on tools to help the testing process and smoothing the edges of the tool.

I use TestNG, WebDriver, and Spring to build my present test framework. I'm pulling segments of this framework out into its own set of OSS libraries so others can re-use them. Right now I can inject custom element types, and I have a few base types added to do form work. It's really rough, and it's not a framework that stands alone; you have to integrated it into your own framework, but I try and keep dependencies to a minimum.