##// END OF EJS Templates
repo-settings: converted repo settings to pyramid...
repo-settings: converted repo settings to pyramid - switched to pyramid views - switched to deform - validation shares the similar schema as API - added new audit-log

File last commit:

r1120:d4155363 default
r1716:24a2983a default
Show More
spec-by-example.rst
72 lines | 1.8 KiB | text/x-rst | RstLexer

Specification by Example

Choices of technology and tools

nix as runtime environment

We settled to use the nix tools to provide us the needed environment for running the tests.

Gherkins as specification language

To specify by example, we settled on Gherkins as the semi-formal specification language.

py.test as a runner

After experimenting with behave and py.test our choice was pytest-bdd because it allows us to use our existing knowledge about py.test and avoids that we have to learn another tool.

Concepts

The logic is structured around the design pattern of "page objects". The documentation of python-selemium contains a few more details about this pattern.

Page Objects

We introduce an abstraction class for every page which we have to interact with in order to validate the specifications.

The implementation for the page objects is inside of the module :mod:`page_objects`. The class :class:`page_objects.base.BasePage` should be used as a base for all page object implementations.

Locators

The specific information how to locate an element inside of the DOM tree of a page is kept in a separate class. This class serves mainly as a data container; it shall not contain any logic.

The reason for keeping the locators separate is that we expect a frequent need for change whenever we work on our templates. In such a case, it is more efficient to have all of thelocators together and update them there instead of having to find every locator inside of the logic of a page object.