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 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. Lenny) to runtests.py script:
cd fab_deploy_tests ./runtests.py <VM name or uid> <what to run>
<what to run> can be misc, deploy, all, 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 htmlcov folder.