Translations by Ballock

The `PPA documentation on Launchpad`_ is fairly comprehensive and should get you up and running in no time.

If you should run into any problems, you can join the `#ubuntu-quality IRC channel`_ to get in touch with developers who can help you.

The Ubuntu Engineering team put together a `list of required test-cases`_, where packages which need tests are put into different categories. Here you can find examples of these tests and easily assign them to yourself.

Sometimes you might want to make new functionality available in a stable release which is not connected to a critical bug fix. For these scenarios you have two options: either you `upload to a PPA <https://help.launchpad.net/Packaging/PPA>`_ or prepare a backport.

Packages in Debian with a testsuite header will also be automatically added when they are synced to Ubuntu.

write the ``debian/tests/control`` based on the `DEP 8 Specification`_,

While Debian does not have an automatic testing infrastructure set up yet, they should still be submitted to Debian, as DEP-8 is a Debian specification and Debian developers or users can still manually run the tests.

The `gvfs tests`_ have comprehensive testing of their functionality and are very interesting because they emulate usage of CDs, Samba, DAV and other bits.

In the `ubiquity tests`_ the upstream test-suite is executed.

This would use the source package in ``/tmp/glib2.0-2.35.7/`` and run the tests from this tree against the package ``glib2.0`` from the archive. The option ``-S`` also supports schemes for bzr, git, and apt sources. If you only specify a source with ``-S`` but do not specify a package name, this will instead build the branch and install the binaries from that build; this is useful if you want to run tests on a newer version than the one packaged in Ubuntu, or the package is not in Ubuntu at all. If use the ``-k`` flag you can log into the virtual machine after the tests were run. This makes it very easy to debug issues.

The `libxml2 tests`_ are very similar. They also run a test-build of a simple piece of C code and execute it.

The `gtk+3.0 tests`_ also do a compile/link/run check in the "build" test. There is an additional "python3-gi" test which verifies that the GTK library can also be used through introspection.

The `auto-package-testing documentation`_ has a lot more valuable information on other testing options.

While this test is very small and basic, it tests quite a number of core components on a system. This may help to uncover critical issues early on.

Then, get the source code from Launchpad::

The downside of this approach is that you test it locally, but can't ensure that this will work in a minimal environment. For example will it be hard to ensure that all the required packages are installed for the tests. With `lp:auto-package-testing`_ we have a more comprehensive testing tool. It uses a pristine virtual machine to run the tests. To set it up, firstly install the needed dependencies::

The test script can be easily executed on its own, but if you want to make sure that the testbed is properly set up, you might want to use ``adt-run`` from the ``autopkgtest`` package to execute the test. The easiest way to do this is to run this command in the source tree::

add the following to the Source section in ``debian/control``::

In ``debian/tests/control`` you specify what to expect from the testbed. So for example you list all the required packages for the tests, if the testbed gets broken during the build or if ``root`` permissions are required. The `DEP 8 specification`_ lists all available options.

The `DEP 8 specification`_ defines how automatic testing can very easily be integrated into packages. To integrate a test into a package, all you need to do is:

autopkgtest: Automatic testing for packages

add a file called ``debian/tests/control`` which specifies the requirements for the testbed,

add the tests in ``debian/tests/``.

Testbed requirements

Below we are having a look at the ``glib2.0`` source package. In a very simple case the file would look like this::

For the test in ``debian/tests/build`` this would ensure that the packages ``libglib2.0-dev`` and ``build-essential`` are installed.

You can use ``@`` in the ``Depends`` line to indicate that you want all the packages installed which are built by the source package in question.

The actual tests

The accompanying test for the example above might be:

Here a very simple piece of C code is written to a temporary directory. Then this is compiled with system libraries (using flags and library paths as provided by `pkg-config`). Then the compiled binary, which just exercises some parts of core glib functionality, is run.

Executing the test

Further examples

This list is not comprehensive, but might help you get a better idea of how automated tests are implemented and used in Ubuntu.

The process of submitting an autopkgtest for a package is largely similar to :doc:`fixing a bug in Ubuntu<./fixing-a-bug>`. Essentially you simply:

run ``bzr branch ubuntu:<packagename>``,

edit ``debian/control`` to enable the tests,

add the ``debian/tests`` directory,

add your test case(s) to ``debian/tests``,

commit your changes, push them to Launchpad, propose a merge and get it reviewed just like any other improvement in a source package.

What you can do

Backporting software updates

Personal Package Archive (PPA)

Using a PPA has a number of benefits. It is fairly straight-forward, you don't need approval of anyone, but the downside of it is that your users will have to manually enable it. It is a non-standard software source.

Official Ubuntu Backports

The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a package in an Ubuntu release has a bug, it should be fixed either through the :doc:`Security Update or the Stable Release Update process<./security-and-stable-release-updates>`, as appropriate.