autotest, the Linux test framework that still ships six cooperating components

Six components, and the module split in setup.py confirms the boundaries

The most useful thing in this repository is the boundary between its parts, and setup.py states it in code. Each component is a separate package with its own setup module, and the top level file imports them all in one place:

import client.setup
import shared.setup
import frontend.setup
import cli.setup
import server.setup
import scheduler.setup
import database_legacy.setup
import tko.setup
import utils.setup
import mirror.setup
import installation_support.setup

The directory listing at the repository root matches that structure exactly. There is a client directory, a server directory, a scheduler directory, a cli directory, a frontend directory, a database_legacy directory, plus shared, utils, mirror, tko, conmux, packages, installation_support and contrib. There are also apache and debian directories, which is a hint about the deployment targets.

The project documentation describes the whole thing as a framework for fully automated testing, designed primarily to test the Linux kernel, though it is also useful for functions such as qualifying new hardware. The name of the database component, database_legacy, and the existence of a tko component both suggest layers that have outlived the current design.

For an evaluator, the practical question is which of those pieces you actually need. Most people need one.

The client is a directory of tests, each a Python class

The client is the engine that executes the tests, and the documentation is specific about its shape. Each autotest test is a directory inside client/tests, and it is represented by a Python class that implements a minimum number of methods.

That layout is the core idea of the framework. A test is a folder containing a class, so the surrounding machinery, the job control, the result reporting and the control files all work against the same unit. Adding a test means adding a directory, not registering a class in a central list.

The client executes client side control files, which the documentation describes as regular Python programs that use the API of the client. Control files are the user's entry point: you write a Python file that selects and runs tests rather than invoking each one by hand.

The documentation also states that the client is what you need if you are a single developer trying out autotest and executing some tests. That is the intended low-commitment path, and the quick start for it is published separately, at the ClientQuickStart page in the readthedocs build.

The server, scheduler and database turn one machine into a grid

The remaining components exist for a single reason: to run tests on many machines and keep the results.

The autotest server is a program that copies the client to remote machines and controls their execution. It runs server side control files, also regular Python programs, but at a higher level of API because the server can control test execution across multiple machines. The documentation says that if you want to perform tests slightly more complex involving more than one machine, you might want the server.

The autotest scheduler is the utility that schedules and triggers job execution on test machines. The autotest database is where test results are stored for test grids, used by the scheduler and by the frontends to store and visualize those results.

The web frontend is a separate application whose backend is written in django and whose user interface is written in gwt, and it lets users trigger jobs and visualize test results. Alternatively there is the autotest command line interface, also written in python.

The last detail is the one that dates the project. The documentation links the interface toolkit to a code.google.com address, and the install advice tells you to check the details regarding appropriate versions of Django that autotest is compatible with. A framework whose web tier depends on a version-matched Django is telling you to plan the upgrade before you start.

Building the documentation locally with sphinx

The documentation ships in the tree and is built with sphinx. The build instructions are spelled out, and they are a good window into what the project expects of a workstation.

For Fedora, install the sphinx package:

    $ sudo yum install python-sphinx

For Ubuntu or Debian:

    $ sudo apt-get install python-sphinx

The read the docs theme is optional and only changes how the in-tree documentation looks:

    $ sudo pip install sphinx_rtd_theme

Then build it and open the result:

    $ make -C documentation html

    $ [your-browser] docs/build/html/index.html

Note that the published documentation lives in two places. There is a build of the latest master branch and of releases on readthedocs, and the documentation also links a build of a specific released version, 0.16.0. That separation matters when you are reading instructions: the version-specific pages describe an older generation of the codebase, while the master branch pages describe the current tree.

A publicly available build of the latest master branch documentation is the fastest way to understand the current control file API before you install anything.

Packaging runs through setup.py and a hand-written Makefile

Installation is not a single wheel. The Makefile at the repository root defines the packaging targets, and each one shells out to setup.py with a Python interpreter found on the path.

source:
	$(PYTHON) setup.py sdist $(COMPILE)

install:
	$(PYTHON) setup.py install --root $(DESTDIR) $(COMPILE)

The build directory for the Debian packaging flow is debian/autotest, the project name is autotest, and the version is read from client/shared/version.py. The make target prints its own options, including make source to create a source package, make install to install on the local system, make builddeb to generate a deb package, and make clean to remove scratch and byte files.

The deb targets run dpkg-buildpackage with fakeroot, and prepare-source renames the generated tarball to the Debian orig naming convention. The spec file, autotest-framework.spec, and the debian directory confirm that a Debian package is a first class output rather than an afterthought.

This is packaging for a machine that installs many components. A developer who wants to run a test on a laptop is better served by the client, and the documentation says so.

A custom licence, a GPL heritage, and the successor project named in the readme

The licence picture needs care. The project documentation states that it is an open-source project under the GPL, and the repository root carries both a LICENSE file and an LGPL_LICENSE file, plus an apache directory that suggests a third component with its own terms. The repository is flagged with a custom licence that GitHub cannot classify, so the LICENSE files in the tree are the authority, and the per-component directories may carry different terms. Read the files in the repository rather than assuming a single licence covers the whole tree.

The maintenance signal is a single date. The last push was on 2026-10-07, and the repository has no GitHub releases, so there is no tag history to follow even though the documentation links a downloads page for stable versions and a specific 0.16.0 documentation build. Configuration files in the root also show the testing era the project lives in, with a .nose.cfg and a tox.ini alongside a .travis.yml and a requirements-travis.txt.

Finally, the readme points at the successor. It asks readers to check Avocado, described as a next generation test automation framework being developed by several of the original Autotest team members. That is the most useful strategic fact in the document for anyone planning a long-term dependency on Autotest. The difference in approach is that Avocado is framed as a replacement generation rather than an extension of the client, server, scheduler and database stack described above. If you are starting from scratch, the readme itself suggests looking there first.

Editorial conclusion

Autotest fits a team that already runs Linux kernel or hardware qualification work and wants a grid with a database, a scheduler and a web frontend rather than a single test runner. It does not fit a small team that just wants to run a test suite on one machine, because the client, the server and the database are separate pieces with their own install steps. Before you commit, read the compatibility note about the Django versions the server supports, check the two licence files in the repository root, and confirm that the master branch documentation you will be reading is newer than the 0.16.0 build linked from the readme.

Frequently asked questions

Official sources

1. autotest/autotest on GitHub
2. Issues
3. Project website
4. README