Best practices | Ranorex Webtestit User Guide
WebtestitUser GuideBest practices

Best practices for minimizing maintenance efforts

There’s no denying that at a certain point you will run into test maintenance when automating your UI tests. As of today, there are no technical possibilities to describe a UI behavior in such a generic way that you won’t have to alter your code. The key to avoiding maintenance hell, i.e. having to spend a majority of your time altering your tests, lies in a well-structured test suite. To keep the maintenance effort as low as possible we’ve collected some best practices for you to follow:
  • Keep all selectors within your Page Objects. Don’t use selectors in your test cases. Use the Page Object Pattern.
  • Design atomic tests. Don’t create tests that are dependent on each other. Don’t pass data between test cases.
  • DRY (Don’t Repeat Yourself): Encapsulate common actions into Page Object actions and call them whenever needed. Facilitate data-driven testing instead of hard-coded values.
tipp icon

Hint

We strongly recommend you to check out our data-driven sample Java project by downloading it from within the application, or directly from our GitHub, and recognize the benefits of this approach.
  • Refactor similar functions into one. If you have an input field and are testing different values to enter in it, pass them as parameters to a generic function.
  • Create robust selectors. The preferred order of selector strategies for locating objects in your website or application should be id, name, css, and xpath. Use Ranorex Selocity to help you find the best selector for the element you want to automate.
  • Keep test data separated from the Page Objects. Specify input values in your test file and pass them as parameters to the Page Object.
  • Name your test cases properly. The automation frameworks supported by Ranorex Webtestit enable you to describe the purpose and the expected outcome of each test case. Be sure to use this opportunity to keep your test suite orderly.
  • Leave the test environment out of your tests. Always design test cases in a way that they are able to run on multiple configurations and environments.