Setting Up a Development Environment

This page describes how to setup a working Python development
environment that can be used in developing Tacker on Ubuntu, Fedora or
Mac OS X. These instructions assume you’re already familiar with
Git and Gerrit, which is a code repository mirror and code review toolset
, however if you aren’t please see this Git tutorial for an introduction
to using Git and this guide for a tutorial on using Gerrit and Git for
code contribution to Openstack projects.

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 tacker tree to make sure any new changes
don’t break existing functionality.

The functional tests are intended to validate actual system
interaction. Mocks should be used sparingly, if at all. Care
should be taken to ensure that existing system resources are not
modified and that resources created in tests are properly cleaned
up.

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

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

With these 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.

Note that the tests can use a database, see tools/tests-setup.sh
on how the databases are set up in the OpenStack CI environment.

You can use nose to run individual tests, as well as use for debugging
portions of your code:

source.venv/bin/activatepipinstallnosenosetests

There are disadvantages to running Nose - the tests are run sequentially, so
race condition bugs will not be triggered, and the full test suite will
take significantly longer than tox & testr. The upside is that testr has
some rough edges when it comes to diagnosing errors and failures, and there is
no easy way to set a breakpoint in the Tacker code, and enter an
interactive debugging session while using testr.

Tox packages and installs the tacker source tree in a given venv
on every invocation, but if modifications need to be made between
invocation (e.g. adding more pdb statements), it is recommended
that the source tree be installed in the venv in editable mode:

# run this only after activating the venv
$ pip install --editable .

Editable mode ensures that changes made to the source tree are
automatically reflected in the venv, and that such changes are not
overwritten during the next tox run.