In addition to providing a class to serve as the top of the page object inheritance tree, Saunter also provides a class that your scripts should inherit from. Actually there are two, though a script will only ever inherit from one.
- saunter.testcase.remotecontrol.SaunterTestCase if you want to use the Selenium Remote Control API
- saunter.testcase.webdriver.SaunterTestCase if you want to use the new WebDriver API. This is done through the Remote WebDriver interface for ease of integration into cloud providers
from saunter.testcase.remotecontrol import SaunterTestCase class CheckLoginExample(SaunterTestCase): @pytest.marks('deep', 'sauce', 'login') def test_incorrect_login(self): pass
The SaunterTestCase class handles the creation of the Selenium session (either locally or to Sauce Labs). It also includes some ‘soft asserts’ that can be used by scripts. Those familiar with Selenium IDE and its various verify_* commands will understand was a ‘soft assert’ is. They will fail the script at the end, but will proceed until that point as if nothing went wrong.
You will find quickly though that you desire a custom assert or verify command inside a script. And similar to with pages, you could modify SaunterTestCase directly, but you then risk losing the code during the next upgrade. Instead, you should create a site-specific TestCase class that inherits from SaunterTestCase and which all your scripts use. This module should live in the modules directory.
from saunter.testcase.webdriver import SaunterTestCase class YourSiteTestCase(SaunterTestCase): def your_custom_assert(self, left, right): return True
With this in place, the example script from the beginning will look like this.
import your_site_test_case class CheckLoginExample(your_site_test_case.YourSiteTestCase): @pytest.marks('deep', 'sauce', 'login') def test_incorrect_login(self): self.your_custom_assert("one", "two")
While it is perfectly doable to inherit directly from SaunterTestCase, it is advisable to inject a layer in between your script and what Saunter provides to isolate scripts from framework changes and to create a single place for site-specific customizations.