Py.Saunter is the Python version of the Saunter test framework and is based on the pytest tool.
Py.Saunter is distributed as a Python egg which means installing it is as easy as
pip install py.saunter
As part of the installation, the pysaunter.py script is added to the Python installation’s scripts directory. This directory is often included in the OS’s system path.
Being an opinionated framework, once installed the location you will use as your base directory needs to be setup. Py.Saunter takes care of this for you using the –new flag.
(Assuming you have your Python installation’s Scripts directory in your path.)
This command will create a few of directories and copy the necessary files for the framework to function. It is a non-destructive operation and can be run multiple times.
Emulating a practice popularized by the Ruby-on-Rails community, there is a conf/saunter.ini.default file. Create a copy of it as conf/saunter.ini. This non-default version will have machine specific information in it and should not be committed to version control. The default version should however.
The saunter.ini.default file has comments describing what the various options do, but some combinations warrant further discussion.
Saunter distinguishes between Scripts and Page Objects. Think of the difference as Scripts are the What and Page Objects as the How. There will be a lot more detail provided around how to create both of these, but for this, it is important to state that they too have a specific place.
- Scripts -> scripts/
- Page Objects -> modules/pages/
Aside from the example projects, these pages also have useful information for creating Scripts and Page Objects.
- When building out Page Objects, it makes sense to inherit from The ‘Base’ Page
- Likewise, your scripts should inherit from SaunterTest case but You Probably Don’t Want to Use SaunterTestCase Directly – Here Is How
- Enabling implicit waits can help address script brittleness, but at some risk
- Locators can be put in page objects in two main ways; understand why having them at the local module level is a better idea in The Great Locator Location Debate
- Extending the Selenium RC API in Saunter
An important part of Saunter is the use of Tags to generate dynamic execution suites. By default, Saunter will run those scripts which have been tagged as shallow. You can specify different flags by using the -m (marks) flag. For example
pysaunter -m website
Will run all the scripts discovered in the scripts directory that have been taggged with website.
While Saunter can be run locally on any machine (and should while you are creating your scripts), it is meant to be run inside a Continuous Integration server. To facilitate this, run results are logged in the Ant JUnit format in the logs directory with the most recent one always available as latest.xml. This is the artifact to consume and archive after each run.
Sometimes the easiest way to figure something out is to look at working examples. While the examples are not included in the distribution, there are complete, working Py.Saunter projects online in github.
There is also auto-generated documentation from the key classes that you will need to interact with available at PyPI
Py.Saunter has been used in a number of large organization in its non-distributed form. There are likely to be a few problem resulting in this new form form of distribution and from more people using it. If you encounter one, don’t be quiet about it. Either