##// END OF EJS Templates
Authentication: cache plugins for auth and their settings in the auth_registry....
Authentication: cache plugins for auth and their settings in the auth_registry. - Before that change on each requests 4x we loaded plugins for authentication, this hit many caches, db invalidation context and loaded the plugins logic each time. This was a heavy performance hit for SVN and other backends as they needed to load that plugins many many times - Since Authentication plugins almost never change, we'll not store the plugins listed for authentication into the authnregistry for each process - For AuthPlugins settings we now also flush plugins settings, and authnregistry cached plugins

File last commit:

r1120:d4155363 default
r4220:5a873939 stable
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.