I've just started automating all the tests our team has (~5000). I'm using Telerik Test Studio for the Silverlight automation. I have some tests written, but I'm quickly realizing that with each test it's becoming harder to maintain. Here are some things I'm wondering:

  1. In Telerik, each test seems to have its own Elements Page, even though they're testing the same Silverlight page. Can I not just reference another test's Elements Page? That would make copy/pasting steps a lot easier since then I wouldn't have to add the elements to each test's Element Page individually.

  2. Does automation allow for running tests on different computers? We have some tests that find folders through a SL directory browser dialog, but even though I'm navigating to tests through object name (not by point/click mouse movement) if I run these tests on another computer it won't properly navigate to that directory.

  3. Are there any good books that can help a beginner learn best practices so I don't create 5k automated tests that aren't maintainable?


2 Answers 2


I presented to the Portland Selenium Users group about creating maintainable, reliable and self-documenting UI automation and I think there's a lot in there that would be relevant regardless of whether you're using Selenium or not. The presentation slide-deck http://files.meetup.com/2891252/Selenium%20Beyond%20the%20Page%20Object%20Pattern.pptx and more importantly the code sample http://files.meetup.com/2891252/BeyondThePageObjectPatternSln.zip are both posted at the meetup web site.

In a nutshell, in the code example, I implement the same test case 7 times, each time applying a step that helps you build better UI automation. The steps are:

  1. Remove sleeps and replace with polling
  2. Add Logging and Comments
  3. Move code to a driver or abstraction layer
  4. Move code to startup/cleanup methods and config class
  5. Move element initialization to a page class
  6. Create helper functions in the page class for common activities
  7. Use data to drive the tests

In the example, the lines of code used to implement a test case start at 85 lines of code, jumps up to 164 lines of code and dramatically ends at only 10 lines of code with most of the functionality abstracted away into helper functions, or the initialize functions.

  • +1 for Slide 6 in presentation. The Evolution of (my) UI Automation - Strikingly similar learning path :)
    – Siva
    Commented Jun 18, 2014 at 4:30
  • Unable to get to the files. Those links take me to "error, page you are looking for does not exist". Are those files available elsewhere?
    – ackmondual
    Commented May 3, 2022 at 0:08

I generally focus on three principles for maintainable automated tests:

  • Hide incidental details
  • Name every important idea
  • Eliminate duplication

Here is a paper where I describe these principles in more detail and apply them to a difficult-to-change test: http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf

The paper uses one particular test tool (Robot Framework), but the principles are likely applicable in other test tools as well. Here is a nice 15-minute video where Robert Martin's applies these principles using FitNesse: http://blog.objectmentor.com/articles/2009/12/07/writing-maintainable-automated-acceptance-tests

I've never used Telerik, so I don't know how well Telerik supports the kinds of abstractions I normally use. But if you write tests using some kind of general-purpose programming language, the principles in my paper apply.

Of course, there's a lot more to test automation than these three principles. But if you master those, your tests will be more maintainable than most.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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