Element 34

A pattern I have used successfully in automation is to create a layer between code that you create at that which your framework provides. This is why you probably don’t want to use SaunterTestCase directly even though you technically could. The same applies for the Selenium APIs.

The Remote Control and WebDriver APIs have different philosophies of design which are reflected in how you extend them. This post is about the Remote Control API specifically.

Python

When a new project is initialized, a tailored.remotecontrol.py module is copied over. It is here that you can make modifications to existing Selenium calls or create entirely new ones. Stripping out comments and such, it will look like this initially.

from saunter.SaunterSelenium import SaunterSelenium

class RemoteControl(SaunterSelenium):
    def __init__(self, *args):
        super(RemoteControl, self).__init__(*args)

Don’t change these lines. Saunter is an opinionated framework and expects this to be here like this. Bad things will happen otherwise. Or more accurately, nothing will happen.

Modifying the API in this module is pretty simple and will typically take one of these forms.

• Renaming:

  def klick(self, locator):
          super(RemoteControl, self).click(locator)

• Addition:

  def triple_click(self, locator):
          super(RemoteControl, self).click(locator)
          super(RemoteControl, self).click(locator)
          super(RemoteControl, self).click(locator)

• Modification:

  def double_click(self, locator):
          super(RemoteControl, self).mouse_down(locator)
          super(RemoteControl, self).mouse_up(locator)
          super(RemoteControl, self).mouse_down(locator)
          super(RemoteControl, self).mouse_up(locator)

Because this makes heavy use of super, reading Raymond Hettinger’s Python’s super() considered super! could be a valuable use of your time.