django-fab-deploy test suite executes fab commands against VirtualBox virtual machines. Full test suite can take a very long time to run (e.g. about 25 minutes for 4mbps broadband, the exact time depends heavily on internet connection speed): all operations are really performed.
VM is rolled back to a clean state or an appropriate snapshot before each test.
This approach is quite extreme but I believe it’s the only way to make sure deployment system works: actually execute the deployment scripts against concrete servers.
pip install -U fabtest pip install 'mock==0.8' pip install coverage
Please follow instructions for fabtest package in order to prepare OS image. django-fab-deploy tests have 1 additional requirement: root user should have ‘123’ password (fabtest example VM images are configured this way).
Pass VM name (e.g. Squeeze) to runtests.py script:
cd fab_deploy_tests ./runtests.py <VM name or uid> <what to run>
<what to run> can be
prepare or any
value acceptable by
unittest.main() (e.g. a list of test cases).
Some tests require additional prepared snapshots in order to greatly speedup
test execution. But there is a chicken or the egg dilemma: these
snapshots can be only taken if software works fine for the VM (at least
tests are passed). So there is a very slow
prepare test suite that ensures
preparing will work.
make sure slow tests are passing:
./runtests.py "VM_NAME" prepare
tests can be run now:
./runtests.py "VM_NAME" all
Tests asking for user input (usually for password) should be considered failed. They mean django-fab-deploy was unable to properly setup server given the root ssh access.
Mercurial can’t preserve 0600 file permissions and ssh is complaining
if private key is 0644. So in order to run tests change
permissions for the
fab_deploy_testskeysid_rsa to 0600:
chmod 0600 fab_deploy_tests/keys/id_rsa
In order to get coverage reports run:
cd fab_deploy_tests ./runcoverage.sh <VM name or uid> <what to run>
html reports will be placed in