In subcommand(for example in verification) we have several groups of methods(managements, launchers, results). It would be nice to split these groups in help message. Before: compare Deprecated. Use `rally verify results' instead. detailed Display results table of a verification with detailed errors. discover Show a list of discovered tests. genconfig Generate Tempest configuration file. import Import Tempest tests results into the Rally database. install Install Tempest. installplugin Install Tempest plugin. list List verification runs. listplugins List all installed Tempest plugins. reinstall Uninstall Tempest and install again. results Display results of verifications. show Display results table of a verification. showconfig Show Tempest configuration file. start Start verification (run Tempest tests). uninstall Remove the deployment's local Tempest installation. uninstallplugin Uninstall Tempest plugin. use Set active verification. After: genconfig Generate Tempest configuration file. install Install Tempest. installplugin Install Tempest plugin. listplugins List all installed Tempest plugins. reinstall Uninstall Tempest and install again. showconfig Show Tempest configuration file. uninstall Remove the deployment's local Tempest installation. uninstallplugin Uninstall Tempest plugin. discover Show a list of discovered tests. start Start verification (run Tempest tests). compare Deprecated. Use `rally verify results' instead. detailed Display results table of a verification with detailed errors. import-results Import Tempest tests results into the Rally database. list List verification runs. results Display results of verifications. show Display results table of a verification. use Set active verification. Also this change transforms all _ to - in cli methods names. Change-Id: I292e71d159ee35e933119f7fb57209f071aa37d4
Testing
Please, don't hesitate to write tests ;)
Unit tests
Files: /tests/unit/*
The goal of unit tests is to ensure that internal parts of the code work properly. All internal methods should be fully covered by unit tests with a reasonable mocks usage.
About Rally unit tests:
- All unit tests are located inside /tests/unit/*
- Tests are written on top of: testtools and mock libs
- Tox is used to run unit tests
To run unit tests locally:
$ pip install tox
$ tox
To run py27, py34, py35 or pep8 only:
$ tox -e <name>
# NOTE: <name> is one of py27, py34, py35 or pep8
To run py27/py34/py35 against mysql or psql
$ export RALLY_UNITTEST_DB_URL="mysql://user:secret@localhost/rally" $ tox -epy27
To run specific test of py27/py34/py35:
$ tox -e py27 -- tests.unit.test_osclients
To get test coverage:
$ tox -e cover
# NOTE: Results will be in ./cover/index.html
To generate docs:
$ tox -e docs
# NOTE: Documentation will be in doc/source/_build/html/index.html
Functional tests
Files: /tests/functional/*
The goal of functional tests is to check that everything works well together. Fuctional tests use Rally API only and check responses without touching internal parts.
To run functional tests locally:
$ source openrc
$ rally deployment create --fromenv --name testing
$ tox -e cli
# NOTE: openrc file with OpenStack admin credentials
Output of every Rally execution will be collected under some reports root in directory structure like: reports_root/ClassName/MethodName_suffix.extension This functionality implemented in tests.functional.utils.Rally.__call__ method. Use 'gen_report_path' method of 'Rally' class to get automatically generated file path and name if you need. You can use it to publish html reports, generated during tests. Reports root can be passed through environment variable 'REPORTS_ROOT'. Default is 'rally-cli-output-files'.
Rally CI scripts
Files: /tests/ci/*
This directory contains scripts and files related to the Rally CI system.
Rally Style Commandments
File: /tests/hacking/checks.py
This module contains Rally specific hacking rules for checking commandments.