From 3225850a61cf497b097fed9f67fe48a6a3c47d36 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Nov 20 2017 07:04:38 +0000 Subject: Describe interactive testing before automated --- diff --git a/source/development/building-modules/testing.rst b/source/development/building-modules/testing.rst index 212bc53..278f8c7 100644 --- a/source/development/building-modules/testing.rst +++ b/source/development/building-modules/testing.rst @@ -1,62 +1,13 @@ Testing modular content in Fedora ================================= -Automated Testing ------------------ - -As described in the -`Continuous Integration `__ page on the -Fedora wiki, Fedora is currently working to improve the level of automated -test coverage for the entire distribution. - - -Modular compose tests -~~~~~~~~~~~~~~~~~~~~~ - -A base set of automated tests check that the core set of modules defined in -Fedora's system profile can all be installed and updated. - -These tests are written as Ansible playbooks, and can be found in the -`compose-tests repository `__. - -These tests are executed in the CentOS CI infrastructure: - -* `Last successful build `__ -* `Latest build `__ - - -Per-module tests in dist-git -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Modules may also define their own individual automated tests, in the ``tests/`` -subdirectory of their respective -`dist-git module repositories `__ - -The `Meta Test Family `__ -project is used to define test cases for whole modules and their resulting RPMs -and container images. - -When a module is built in Fedora's infrastructure and MTF tests are available -in its repository, they will be run afterwards by -`Taskotron `__. - - -Per-package tests -~~~~~~~~~~~~~~~~~ - -Independently of the modular build process, individual packages may also -define their own automated tests, both as part of the ``%check`` section in -their RPM spec file, as well as in the ``tests/`` subdirectory of their -respective -`dist-git RPM repositories `__ - - Interactive Testing ------------------- If the automated tests are failing, or if a new module is being built for the first time, it is useful to be able to check modules interactively before they -make their way into an official compose. +make their way into an official compose. (For details on the regular testing +of modules and their contents, see the :ref:`automated-testing` section below) The interactive testing guide below assumes that ``fedpkg module-build`` is succeeding - if that isn't the case, then the module and package build logs @@ -117,3 +68,55 @@ The most common problems that are encountered despite a successful build and passing integration tests are dependency resolution issues when attempting to install a module. The :ref:`resolving-dependency-issues` section provides more guidance on dealing with such situations. + + +.. _automated-testing: + +Automated Testing +----------------- + +As described in the +`Continuous Integration `__ page on the +Fedora wiki, Fedora is currently working to improve the level of automated +test coverage for the entire distribution. + + +Modular compose tests +~~~~~~~~~~~~~~~~~~~~~ + +A base set of automated tests check that the core set of modules defined in +Fedora's system profile can all be installed and updated. + +These tests are written as Ansible playbooks, and can be found in the +`compose-tests repository `__. + +These tests are executed in the CentOS CI infrastructure: + +* `Last successful build `__ +* `Latest build `__ + + +Per-module tests in dist-git +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Modules may also define their own individual automated tests, in the ``tests/`` +subdirectory of their respective +`dist-git module repositories `__ + +The `Meta Test Family `__ +project is used to define test cases for whole modules and their resulting RPMs +and container images. + +When a module is built in Fedora's infrastructure and MTF tests are available +in its repository, they will be run afterwards by +`Taskotron `__. + + +Per-package tests +~~~~~~~~~~~~~~~~~ + +Independently of the modular build process, individual packages may also +define their own automated tests, both as part of the ``%check`` section in +their RPM spec file, as well as in the ``tests/`` subdirectory of their +respective +`dist-git RPM repositories `__