##// END OF EJS Templates
autocomplete: allow to pass in a GET flag to control if non-active users should be returned in...
autocomplete: allow to pass in a GET flag to control if non-active users should be returned in autocomplete data.

File last commit:

r1:854a839a default
r226:6371ca5e default
Show More
spec-by-example.rst
75 lines | 1.9 KiB | text/x-rst | RstLexer
project: added all source files and assets
r1
.. _test-spec-by-example:
==========================
Specification by Example
==========================
.. Avoid duplicating the quickstart instructions by importing the README
file.
.. include:: ../../../acceptance_tests/README.rst
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 locators together and update them there instead of having
to find all locators inside of the logic of a page object.