mirror of
https://github.com/kevingruesser/bootstrap-vz.git
synced 2025-12-16 06:50:21 +00:00
Up until now I didn't see the point of using spaces for indentation. However, the previous commit (a18bec3) was quite eye opening. Given that python is an indentation aware language, the amount of mistakes that went unnoticed because tabs and spaces were used at the same time (tabs for indentation and spaces for alignment) were unacceptable. E101,W191 have been re-enable in the tox flake8 checker and the documentation has been modified accordingly. The following files have been left as-is: * bootstrapvz/common/assets/extlinux/extlinux.conf * bootstrapvz/common/assets/init.d/expand-root * bootstrapvz/common/assets/init.d/generate-ssh-hostkeys * bootstrapvz/common/assets/init.d/squeeze/generate-ssh-hostkeys * bootstrapvz/plugins/docker_daemon/assets/init.d/docker * bootstrapvz/providers/ec2/assets/bin/growpart * bootstrapvz/providers/ec2/assets/grub.d/40_custom * bootstrapvz/providers/ec2/assets/init.d/ec2-get-credentials * bootstrapvz/providers/ec2/assets/init.d/ec2-run-user-data * docs/_static/taskoverview.coffee * docs/_static/taskoverview.less * tests/unit/subprocess.sh |
||
|---|---|---|
| .. | ||
| docker | ||
| ec2 | ||
| virtualbox | ||
| __init__.py | ||
| README.rst | ||
System testing providers are implemented on top of the abstraction
that is the testing harness.
Implementation
--------------
At their most basic level all they need to implement is
the ``boot_image()`` function, which, when called, boots the image
that has been bootstrapped. It should yield something the test can use to
ascertain whether the image has been successfully bootstrapped
(i.e. a reference to the bootlog or an object with various functions to
interact with the booted instance). How this is implemented is up to the
individual provider.
A ``prepare_bootstrap()`` function may also be implemented, to ensure that the
bootstrapping process can succeed (i.e. create the AWS S3 into which an image
should be uploaded).
Both functions are generators that yield, so that they may clean up any created
resources, once testing is done (or failed, so remember to wrap ``yield`` in a
``try:.. finally:..``).
Debugging
---------
When developing a system test provider, debugging through multiple
invocations of ``tox`` can be cumbersome. A short test script, which sets
up logging and invokes a specific test can be used instead:
Example:
.. code-block:: python
#!/usr/bin/env python
from tests.system.docker_tests import test_stable
from bootstrapvz.base.main import setup_loggers
setup_loggers({'--log': '-', '--color': 'default', '--debug': True})
test_stable()