forked from canonical/operator
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: optionally install Scenario with
ops[testing]
and expose the …
…names in ops.testing (canonical#1381) Add a new optional install `testing`, e.g. `pip install ops[testing]`. This pulls in a compatible version of `ops-scenario`, and exposes the Scenario names in the `ops.testing` namespace, alongside Harness. `pip install ops[harness]` is also supported to ease the (far off, presumably 3.0) transition to Harness being moved out of the base install. It currently installs no extra dependencies, so is the same as `pip install ops` but a forward-looking charm would use `pip install ops[harness]` (or `pip install ops[harness, testing]`) if using Harness. Requires ops-scenario 7.0.5, which has the required adjustments to support insertion into `ops.testing`. The `ActionFailed` name exists in both `ops._private.harness` and `scenario.context`. This is handled by adjusting the Harness class to support the functionality of both and monkeypatching that into Scenario until Scenario starts using it. It's compatible with both Harness and Scenario, but will have empty data in an attribute (which attribute depends on which framework is used). The `Container` name in `ops.testing`, which is only present for backwards compatibility, is also overwritten if ops-scenario is installed. If anyone is actually using `ops.testing.Container` instead of `ops.Container` then they'll need to fix their code before using `ops[testing]` (or ops-scenario combined with the release of ops with this change). A very basic unit test is added to make sure that Scenario tests work (all the actual Scenario tests are in the ops-scenario repo) if ops-scenario/ops[testing] is installed (this is the case for `tox -e unit`). A test is also added to ensure that all of the Scenario names are documented, since `automodule` isn't used any more. Also adjusts the documentation to include the new framework in ops.testing. --------- Co-authored-by: Ben Hoyt <benhoyt@gmail.com> Co-authored-by: Dima Tisnek <dimaqq@gmail.com>
- Loading branch information
1 parent
b733529
commit b68c90f
Showing
14 changed files
with
510 additions
and
117 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
.. _harness: | ||
|
||
Harness (legacy unit testing) | ||
============================= | ||
|
||
.. deprecated:: 2.17 | ||
The Harness framework is deprecated and will be moved out of the base | ||
install in a future ops release. Charm authors that don't want to upgrade | ||
will still be able to use it with ``pip install ops[harness]``. | ||
|
||
The Harness API includes: | ||
|
||
- :class:`ops.testing.Harness`, a class to set up the simulated environment, | ||
that provides: | ||
|
||
- :meth:`~ops.testing.Harness.add_relation` method, to declare a relation | ||
(integration) with another app. | ||
- :meth:`~ops.testing.Harness.begin` and :meth:`~ops.testing.Harness.cleanup` | ||
methods to start and end the testing lifecycle. | ||
- :meth:`~ops.testing.Harness.evaluate_status` method, which aggregates the | ||
status of the charm after test interactions. | ||
- :attr:`~ops.testing.Harness.model` attribute, which exposes e.g. the | ||
:attr:`~ops.Model.unit` attribute for detailed assertions on the unit's state. | ||
|
||
.. warning:: The Harness API has flaws with resetting the charm state between | ||
Juju events. Care must be taken when emitting multiple events with the same | ||
Harness object. | ||
|
||
.. note:: | ||
Unit testing is only one aspect of a comprehensive testing strategy. For more | ||
on testing charms, see `Charm SDK | Testing <https://juju.is/docs/sdk/testing>`_. | ||
|
||
|
||
.. autoclass:: ops.testing.ActionFailed | ||
:noindex: | ||
.. autoclass:: ops.testing.ActionOutput | ||
.. autoclass:: ops.testing.ExecArgs | ||
.. autoclass:: ops.testing.ExecResult | ||
.. autoclass:: ops.testing.Harness |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,79 +1,72 @@ | ||
|
||
ops library API reference | ||
========================= | ||
API reference | ||
============= | ||
|
||
The `ops` library is a Python framework for writing and testing Juju charms. | ||
|
||
See more: `Charm SDK documentation <https://juju.is/docs/sdk>`_ | ||
|
||
The library provides: | ||
The library (`available on PyPI`_) provides: | ||
|
||
- :ref:`ops_main_entry_point`, used to initialise and run your charm; | ||
- :ref:`ops_module`, the API to respond to Juju events and manage the application; | ||
- :ref:`ops_main_entry_point`, used to initialise and run your charm; | ||
- :ref:`ops_pebble_module`, the Pebble client, a low-level API for Kubernetes containers; | ||
- :ref:`ops_testing_module`, the framework for unit testing charms in a simulated environment; | ||
- the APIs for unit testing charms in a simulated environment: | ||
|
||
- :doc:`State-transition testing </state-transition-testing>`. This is the | ||
recommended approach (it was previously known as 'Scenario'). | ||
- :doc:`Harness </harness>`. This is a deprecated framework, and has issues, | ||
particularly with resetting the charm state between Juju events. | ||
|
||
You can structure your charm however you like, but with the `ops` library, you | ||
get a framework that promotes consistency and readability by following best | ||
practices. It also helps you organise your code better by separating different | ||
aspects of the charm, such as managing the application’s state, handling | ||
aspects of the charm, such as managing the application's state, handling | ||
integrations with other services, and making the charm easier to test. | ||
|
||
.. _available on PyPI: https://pypi.org/project/ops/ | ||
|
||
.. toctree:: | ||
:hidden: | ||
:maxdepth: 2 | ||
:caption: Contents: | ||
|
||
self | ||
state-transition-testing | ||
harness | ||
|
||
.. _ops_module: | ||
|
||
ops module | ||
========== | ||
ops | ||
--- | ||
|
||
.. automodule:: ops | ||
:exclude-members: main | ||
|
||
|
||
.. _ops_main_entry_point: | ||
|
||
ops.main entry point | ||
==================== | ||
-------------------- | ||
|
||
The main entry point to initialise and run your charm. | ||
|
||
.. autofunction:: ops.main | ||
|
||
|
||
legacy main module | ||
------------------ | ||
|
||
.. automodule:: ops.main | ||
:noindex: | ||
|
||
|
||
.. _ops_pebble_module: | ||
|
||
ops.pebble module | ||
================= | ||
ops.pebble | ||
---------- | ||
|
||
.. automodule:: ops.pebble | ||
|
||
|
||
.. _ops_testing_module: | ||
|
||
ops.testing module | ||
================== | ||
|
||
.. autoclass:: ops.testing.ActionFailed | ||
.. autoclass:: ops.testing.ActionOutput | ||
.. autoclass:: ops.testing.ExecArgs | ||
.. autoclass:: ops.testing.ExecResult | ||
.. autoclass:: ops.testing.Harness | ||
|
||
|
||
Indices | ||
======= | ||
|
||
* :ref:`genindex` | ||
* :ref:`modindex` | ||
* :ref:`search` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.