Snaps are self-contained applications designed with ease of use, security and portability in mind. They bundle their necessary dependencies, so they can work and run without modifications across numerous Linux distributions. How many? More than 40.

Yet, often when technology is strongly associated with a particular product, in this case snaps and Ubuntu, it is easy to assume that the two coincide and overlap. In reality, behind the scenes, a lot of effort is put into making sure snaps perform well on all the different non-Ubuntu distributions. In this article, we want to tell you what the snapd has done for us – apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health.

Find the source, Tux

Snapd is an open-source project, hosted on GitHub. Anyone, with sufficient coding skills, can grab the code, look at the different bits and pieces, and even compile their own version of snapd. A big part of the source tree includes definitions for different ways and methods of testing snapd – on Ubuntu as well as other distributions.

There is a wide range of static unit tests, integration tests and regressions tests. A good place to start is to look at the main section of the test directory. The tests are written in YAML, so if you’re already a snap developer, the logic in the declarations will look familiar. Some of the tests are platform-specific and will only run on some systems. Others will cover all the supported distributions. In most cases, we’re talking about hundreds of tests. For instance:

On top of the integration tests, the snapd team also runs thousands of unit tests on the supported different distributions. The idea is to ensure every Linux gets the same consistent experience.

The tests include a wide range of functionality, including D-Bus, portals, classic confinement, aliases declaration, the use of bases, NFS support, parallel installs, refreshes, and more, even tests like making sure that the LXD snap works on a system using SELinux in enforcing mode. For example, the snapd also runs the desktop interface test, to ensure the interface works correctly, and allows access to different desktop-specific resources.

summary: Ensure that the desktop interface works.
details: |
    The desktop interface allows access to different resources.
    The test-snapd-desktop snap checks files and dirs are accessible through the
    desktop interface.
systems:
    - -amazon-linux-2-*
    - -centos-7-*
    - -ubuntu-14.04-*
    - -ubuntu-core-*
prepare: |
    echo "Given the desktop snap is installed"
    snap try "$TESTSLIB"/snaps/test-snapd-desktop
    tests.session -u test prepare
restore: |
    tests.session -u test restore
execute: |
    dirs="/var/cache/fontconfig /usr/share/icons /usr/share/pixmaps"
    files="/etc/xdg/user-dirs.conf /etc/xdg/user-dirs.defaults"
...

Spread testing

The snapd team uses an open-source tool called spread for testing task scheduling. Spread is designed to simplify testing, and also ensure that the automation does not become more complex and time-consuming than the development of the testing logic itself.

For integration tests, there is one declared task.yaml, which covers at least one test. Sometimes, a specific spread test task.yaml file can declare variants (a mechanism in spread that replicates tasks with minor variations), which means that one task.yaml ends up becoming multiple individual test runs in place.

If you’ve never done integration testing, some of the above can appear a little intimidating. However, most spread tests are documented and self-explanatory. Test summary description, code comments and echo statements also provide a good indication of what the test is doing at runtime.

Getting involved

The cross-distro compatibility matrix also goes beyond formal testing. Some members of the snap ecosystem team run non-Ubuntu distributions, both as a preferred choice as well as to help validate the snap user experience on these other systems.

There are also various ways and methods you can get involved in ensuring snapd works as smoothly and elegantly as possible. Code contributions are the obvious choice. Running and testing snaps on your distro is also a good way of exposing any bugs or inconsistencies.

If you’re a developer or a keen snap user, you may also be interested in building non-Ubuntu bases. As part of their confinement and portability design, snaps utilize the concept of a base, an underlying set of libraries that acts as a runtime environment for the snaps. Today, there are three principal bases in use – core (only as an ESM base), core18 and core20, the last two based off of Ubuntu 18.04 LTS and Ubuntu 20.04 LTS, respectively. But you may also be interested in other bases, like Fedora or RHEL perhaps.

There is already a proof-of-concept Fedora 30 base, which might help you get started. You can also reach out, to figure out which (minimal) requirements and dependencies are needed to satisfy both the security and runtime aspects of your effort.

Summary

Despite its obvious, strong Ubuntu roots, snapd is a cross-distro effort, with a great amount of care and attention invested in making sure all Linux users have the same experience. Almost on a daily basis, thousands upon thousands of tests are run, as part of a complex framework built on top of the spread utility. The work is far from done, so if you have any questions or ideas, please join our forum, and let us know your thoughts. After all, ask not what snapd can do for your distro, ask what your distro can do for snapd!

P.S. No Monty Python fans were compiled or tested during the preparation of this article.