openstack/keystone
Code Issues Proposed changes

updating testing documentation

Browse Source 
Change-Id: I78c55c3050573d6430028bfc3c3c5d8a8c3e93b0
This commit is contained in:
Joe Heck 2012-07-12 16:16:34 +00:00
parent 2a909ee83d
commit 60fa32b256
2 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/configuration.rst
View File

@ -773,8 +773,8 @@ example::
Configuring the LDAP Identity Provider
===========================================================
As an alternative to the SQL Databse backing store, Keystone can Use a
Directory server to provide the Identity service. An example Schema
As an alternative to the SQL Databse backing store, Keystone can use a
directory server to provide the Identity service. An example Schema
for openstack would look like this::
dn: cn=openstack,cn=org

22
doc/source/developing.rst
View File

@ -90,8 +90,14 @@ Test Structure
``./run_test.sh`` uses its python cohort (``run_tests.py``) to iterate
through the ``tests`` directory, using Nosetest to collect the tests and
invoke them using an OpenStack custom test running that displays the tests
as well as the time taken to
run those tests.
as well as the time taken to run those tests.
Not all of the tests in the tests directory are strictly unit tests. Keystone
intentionally includes tests that run the service locally and drives the
entire configuration to achieve basic functional testing.
For the functional tests, an in-memory key-value store is used to keep the
tests fast.
Within the tests directory, the general structure of the tests is a basic
set of tests represented under a test class, and then subclasses of those
@ -104,9 +110,13 @@ this projects etc/ directory. ``test_backend_sql.py`` subclasses those tests,
changing the configuration by overriding with configuration files stored in
the tests directory aimed at enabling the SQL backend for the Identity module.
Likewise, ``test_cli.py`` takes advantage of the tests written aainst
``test_keystoneclient`` to verify the same tests function through different
drivers.
Likewise, ``test_keystoneclient.py`` takes advantage of the tests written
against ``KeystoneClientTests`` to verify the same tests function through
different drivers and releases of the Keystone client.
The class ``CompatTestCase`` does the work of checking out a specific version
of python-keystoneclient, and then verifying it against a temporarily running
local instance to explicitly verify basic functional testing across the API.
Testing Schema Migrations
-------------------------
@ -134,7 +144,7 @@ of your data during migration.
Writing Tests
-------------
To add tests covering all drivers, update the base test class
To add tests covering all drivers, update the relevant base test class
(``test_backend.py``, ``test_legacy_compat.py``, and
``test_keystoneclient.py``).