testing.rst 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384
  1. Running tests
  2. =============
  3. In the spirit of the library's :doc:`design_goals`, the aim is to have thorough
  4. tests for the entire library. This page explains the testing philosophy and
  5. shows how to run the tests locally.
  6. Testing philosophy
  7. ------------------
  8. Our testing goals are to:
  9. 1. Write one set of tests that all provider implementations must pass.
  10. 2. Make that set of tests a 'conformance' test suite, which validates that each
  11. implementation correctly implements the CloudBridge specification.
  12. 3. Make the test suite comprehensive enough that a provider which passes all
  13. the tests can be used safely by an application with no additional testing.
  14. In other words, the CloudBridge specification and accompanying test suite
  15. must be comprehensive enough that no provider specific workarounds, code or
  16. testing is required.
  17. 4. For development, mock providers may be used to speed up the feedback cycle,
  18. but providers must also pass the full suite of tests when run against actual
  19. cloud infrastructure to ensure that we are not testing against an idealised
  20. or imagined environment.
  21. 5. Aim for 100% code coverage.
  22. Running tests
  23. -------------
  24. To run the test suite locally:
  25. 1. Install `tox`_ with :code:`pip install tox`
  26. 2. Export all environment variables listed in ``tox.ini`` (under ``passenv``)
  27. 3. Run ``tox`` command
  28. This will run all the tests for all the environments defined in file
  29. ``tox.ini``.
  30. Specific environment and infrastructure
  31. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  32. If you’d like to run the tests on a specific environment only, say Python 2.7,
  33. against a specific infrastructure, say aws, use a command like this:
  34. ``tox -e py27-aws``. The available provider names are listed in the
  35. `ProviderList`_ class (e.g., ``aws`` or ``openstack``).
  36. Specific test cases
  37. ~~~~~~~~~~~~~~~~~~~~
  38. You can run a specific test case, as follows:
  39. ``tox -- tests/test_image_service.py:CloudImageServiceTestCase.test_create_and_list_imag``
  40. It can also be restricted to a particular environment as follows:
  41. ``tox -e "py27-aws" -- tests/test_cloud_factory.py:CloudFactoryTestCase``
  42. See nosetest documentation for other parameters that can be passed in.
  43. Using unittest directly
  44. ~~~~~~~~~~~~~~~~~~~~~~~
  45. You can also run the tests against your active virtual environment directly
  46. with ``python setup.py test``. You will need to set the ``CB_TEST_PROVIDER``
  47. environment variable prior to running the tests, or they will default to
  48. ``CB_TEST_PROVIDER=aws``.
  49. You can also run a specific test case, as follows:
  50. ``python setup.py test -s tests.test_cloud_factory.CloudFactoryTestCase``
  51. Using a mock provider
  52. ~~~~~~~~~~~~~~~~~~~~~
  53. Note that running the tests may create various cloud resources, for which you
  54. may incur costs. For the AWS cloud, there is also a mock provider (`moto`_) that
  55. will simulate AWS resources. You can use ``CB_TEST_PROVIDER=mock`` to run tests
  56. against the mock provider only, which will provide faster feedback times.
  57. Alternatively you can run the mock tests through tox.
  58. ``tox -e "py27-mock"``
  59. .. _design goals: https://github.com/CloudVE/cloudbridge/
  60. blob/master/README.rst
  61. .. _tox: https://tox.readthedocs.org/en/latest/
  62. .. _ProviderList: https://github.com/CloudVE/cloudbridge/blob/master/
  63. cloudbridge/cloud/factory.py#L15
  64. .. _moto: https://github.com/spulec/moto