House Rules for Automation

Automation Constitution: Stay Put, Stay SOLID
Automation Coding is NO different from any other application development. We take every measure to make our code easy to maintain, and easy to extend. How can we achieve that? Via SOLID principles applicable for software development:

Figure 1: SOLID principles

Applying SOLID to Automation, we get our House Rules:

  • Rule Number 1: Choose a pattern to organize your code.
    Apply Page Object Pattern if you know nothing better. Use page object class to abstract UI and model its page behavior. Any UI change on this page, we only need to come here and here only for modification.

    If a new page is added in the application, we extend our automation by adding a new page object class for it. Existing code is not affected.

    All page objects are created from a central place PageFactory, hiding details from the client

  • Rule Number 2: Clear separation between Page Object classes, Test Case Definition Classes, and Run files
    Figure 2: Different chunk servers different puropose

    These 3 big chunks undertake different responsibilities and shall be loosely decoupled from each other.  Each shall be put in their own package.

      You only need to go to one single place for modification:

      • If AUT is changed, go modify the corresponding Page Object Class, or add new Page Object class if a new page is added in AUT
      • If an existing test case is modified, all you need to do is to go modifying your test case definition class
      • If you want to run your suite in a new environment, simply go modifying your run file.
    • Rule Number 3: Design resilient element locating strategy. Avoid xpath
      Xpath is maintenance nightmare:

      • Xpath is brittle and subjects to frequent changes
      • xPath has bad readability, and Locating by xPath is slow
      • Some browsers such as old IE doesn’t support xpath, thus violating our rule of ‘write code once, and run it everywhere’ rule
    • Rule Number 4: Fail Hard, with grace
      • We shall continue with the test execution even after an issue is found or some checking fails, till we cannot, or make no sense, to go further.
      • For failed cases, we shall take screenshot at each moment when an error/exception we found or fun into.
      • We can decorate Junit’s ErrorCollector class to collect errors and take screenshot at the same time<

Leave a Reply

Your email address will not be published. Required fields are marked *