Page Object Pattern may solve your UI Automation Tests maintenance problem

UI Automation Testing Gone Wrong?

Consider the following example: 

To automate a website, we will download an automation tool. Using screen recorder will navigate to your website and go click, click, type, click, type, tab, type, tab, type, click and assert. Then you replay the recording and it works. Sweet!! So you export the actions as a test script, put it into your code, wrap it in a test and execute the test and see the browser come alive before your eyes and your tests run very smoothly. You get very excited, share your findings with your colleagues and show it off to your boss and they get very excited and go: "Automate ALL THE THINGS"

A week later and you have 10 automated UI tests and everything seems great. Then the business asks you to replace the username with the email address as it has caused some confusion amongst users, and so you do. Then like any other great programmer you run your UI test suite, only to find 90% of your tests are broken because for each test you are logging the user in with username and the field name has changed and it takes you two hours to replace all the references to username in your tests with email and to get the tests green again. The same thing happens over and over again and at some point you find yourself spending hours a day fixing broken tests: tests that didn't break because something went wrong with your code; but because you changed a field name in your database/model or you restructured your page slightly. A few weeks later you stop running your tests because of this huge maintenance cost, and you conclude that UI testing gone wrong.

You should NOT use any screen recorder to develop your test cases. That said, it's not the screen recorder itself that leads to a brittle test suite; it's the code they generate that has inherent maintainability issues. Many developers still end up with a brittle UI test suite even without using screen recorders just because their tests exhibit the same attributes.

What is wrong with this test?

• This is procedural code. One of the main issues of this style of coding is readability or lack thereof. If you want to change the test, or if it breaks because one of the involved pages has changed, you will have a hard time figuring out what to change and to draw a line between functionality sections; because it's all a big pile of code where we get the 'driver' to find an element on the page and to do something with it. No modularity.
• This one test by itself might not have much duplication, but a few more tests like this and you will have a lot of duplicated selector and logic to interact with web pages from different tests. For example By.Id("UserName") selector will be duplicated in all tests that require registration, anddriver.FindElement(By.Id("UserName")).Clear() anddriver.FindElement(By.Id("UserName")).SendKeys("") are duplicated anywhere you want to interact with UserName textbox. Then there is the whole registration form, and checkout form etc. that will be repeated in all tests needing to interact with them! Duplicated code leads to maintainability nightmares.
• There are a lot of magic strings everywhere, which again is a maintainability issue.

Introducing the Page Object Pattern

A lot of the above-mentioned issues are rooted in the procedural nature of the test script and the solution is easy: Object Orientation.

Page Object is a pattern used to apply object orientation to UI tests. From the Selenium wiki:

Within your web app's UI, there are areas that your tests interact with. A Page Object simply models these as objects within the test code. This reduces the amount of duplicated code and means that if the UI changes, he fix need only be applied in one place.

The idea is that for each page in your application/website you want to create one Page Object. Page Objects are basically the UI automation equivalent of your web pages.

More details are available @ http://code.tutsplus.com/articles/maintainable-automated-ui-tests--net-35089