bootstrap-vz/tests/system/providers
Anders Ingemann f62c8ade99 Convert indentation from tabs to spaces (4)
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
2016-06-04 11:38:16 +02:00
..
docker Convert indentation from tabs to spaces (4) 2016-06-04 11:38:16 +02:00
ec2 Convert indentation from tabs to spaces (4) 2016-06-04 11:38:16 +02:00
virtualbox Convert indentation from tabs to spaces (4) 2016-06-04 11:38:16 +02:00
__init__.py Rename integration tests to system tests, since they cover the entire system 2016-03-04 00:48:48 +01:00
README.rst Compat with new sphinx 2016-03-04 01:21:52 +01:00

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()