TESTING

Testing Quantum
=============================================================

Overview

    The unit tests are meant to cover as much code as possible and should
    be executed without the service running. They are designed to test
    the various pieces of the quantum tree to make sure any new changes
    don't break existing functionality.

Running tests

    There are two mechanisms for running tests: run_tests.sh and tox.
    Before submitting a patch for review you should always ensure all unit
    test pass; a tox run is triggered by the jenkins gate executed on gerrit
    for each patch pushed for review.

    With both mechanisms you can either run the tests in the standard
    environment or create a virtual environment to run them in.

    By default after running all of the tests, any pep8 errors
    found in the tree will be reported.

Running individual tests

    For running individual test modules or cases, you just need to pass
    the dot-separated path to the module you want as an argument to it.

    For executing a specific test case, specify the name of the test case
    class separating it from the module path with a colon.

    For example, the following would run only the JSONV2TestCase tests from
    quantum/tests/unit/test_api_v2.py:

      $ ./run_tests.sh quantum.tests.unit.test_api_v2:JSONV2TestCase

    or

      $ ./tox quantum.tests.unit.test_api_v2:JSONV2TestCase

Adding more tests

    Quantum has a fast growing code base and there is plenty of areas that
    need to be covered by unit tests.

    To get a grasp of the areas where unit tests are needed, you can check
    current coverage by running:

    $ ./run_tests.sh -c

Development process

    It is expected that any new changes that are proposed for merge come with
    unit tests for that feature or code area. Ideally any bugs fixes that are
    submitted also have unit tests to prove that they stay fixed!
    In addition, before proposing for merge, all of the current unit tests
    should be passing.