Differential D5395 Diff 19324 docs/tutorials/testing.rst

Changeset View

Standalone View

docs/tutorials/testing.rst

Show First 20 Lines • Show All 60 Lines • ▼ Show 20 Lines	* ``click.testing.CliRunner``: to simplify testing of Click command-line interfaces.
https://click.palletsprojects.com/en/7.x/api/#click.testing.CliRunner		https://click.palletsprojects.com/en/7.x/api/#click.testing.CliRunner

Testing guidelines		Testing guidelines
------------------		------------------

General considerations		General considerations
^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^

We mostly do functional tests, and unit-testing when more ganularity is needed. By this,		We mostly do functional tests, and unit-testing when more granularity is needed. By this,
we mean that we test each functionality and invariants of a component, without isolating		we mean that we test each functionality and invariants of a component, without isolating
it from its dependencies systematically. The goal is to strike a balance between test		it from its dependencies systematically. The goal is to strike a balance between test
effectiveness and test maintenance. However, the most critical parts, like the storage		effectiveness and test maintenance. However, the most critical parts, like the storage
service, get more extensive unit-testing.		service, get more extensive unit-testing.

Organize tests		Organize tests
^^^^^^^^^^^^^^		^^^^^^^^^^^^^^

* In order to test a component (module, class), one must start by identifying its sets of		* In order to test a component (module, class), one must start by identifying its sets of
functionalities and invariants (or properties).		functionalities and invariants (or properties).
* One test may check multiples properties or commonly combined functionalities, if it can		* One test may check multiples properties or commonly combined functionalities, if it can
fit in a short descriptive name.		fit in a short descriptive name.
* Organize tests in multiple modules, one for each aspect or subcomponent tested.		* Organize tests in multiple modules, one for each aspect or subcomponent tested.
e.g.: initialization/configuration, db/backend, service API, utils, cli, etc.		e.g.: initialization/configuration, db/backend, service API, utils, CLI, etc.

Test data		Test data
^^^^^^^^^		^^^^^^^^^

Each repository has its own ``tests`` directory, some such as listers even have one for		Each repository has its own ``tests`` directory, some such as listers even have one for
each lister type.		each lister type.

* Put any non-trivial test data, used for setup or mocking, in (potentially compressed)		* Put any non-trivial test data, used for setup or mocking, in (potentially compressed)
Show All 32 Lines