Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More unit test documentation #314

Merged
merged 6 commits into from
Apr 23, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 27 additions & 1 deletion HACKING.rst
Original file line number Diff line number Diff line change
Expand Up @@ -159,7 +159,7 @@ Unit Testing

cloud-init uses `pytest`_ to run its tests, and has tests written both
as ``unittest.TestCase`` sub-classes and as un-subclassed pytest tests.
The following guidelines should be following:
The following guidelines should be followed:

* For ease of organisation and greater accessibility for developers not
familiar with pytest, all cloud-init unit tests must be contained
Expand All @@ -169,6 +169,7 @@ The following guidelines should be following:

* pytest test classes should use `pytest fixtures`_ to share
functionality instead of inheritance

* As all tests are contained within classes, it is acceptable to mix
``TestCase`` test classes and pytest test classes within the same
test file
Expand All @@ -194,6 +195,24 @@ The following guidelines should be following:
only introduced in `pytest 3.0`_. Such functions must instead use
the ``pytest.yield_fixture`` decorator.

* Only the following built-in fixtures are available
[#fixture-list]_:

* ``cache``
* ``capsys``
* ``capfd``
* ``record_xml_property``
* ``monkeypatch``
* ``pytestconfig``
* ``recwarn``
* ``tmpdir_factory``
* ``tmpdir``

* Variables/parameter names for ``Mock`` or ``MagicMock`` instances
should start with ``m_`` to clearly distinguish them from non-mock
variables

* For example, ``m_readurl`` (which would be a mock for ``readurl``)

.. _pytest: https://docs.pytest.org/
.. _pytest fixtures: https://docs.pytest.org/en/latest/fixture.html
Expand Down Expand Up @@ -223,3 +242,10 @@ variable annotations specified in `PEP-526`_ were introduced in Python

.. _PEP-484: https://www.python.org/dev/peps/pep-0484/
.. _PEP-526: https://www.python.org/dev/peps/pep-0526/

.. [#fixture-list] This list of fixtures (with markup) can be
reproduced by running::

py.test-3 --fixtures -q | grep "^[^ ]" | grep -v no | sed 's/.*/* ``\0``/'

in a xenial lxd container with python3-pytest installed.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated: when are we gonna start testing with a newer LTS by default?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis already tests against the latest PyPI packages by default. So in one sense, we already do.

That said, the reason for this constraint is not our upstream CI testing, it's because we backport the latest cloud-init upstream to xenial, and the unit tests run as part of the package build. This is why Travis has a separate job to test against the xenial versions of our dependencies. So in another sense, the earliest LTS we want the tests (and cloud-init in general) to run on won't change until, at the earliest, xenial leaves standard support in April 2021.