initramfs/testing: add unit tests for initrd scripts

[zyga]

This patch adds a number of support files that allows testing initrd
scripts via a high-level language (Python 3).

The main idea is that function-level tests are described in Python and
are executed via qemu on a virtual machine running the desired kernel,
the stock initrd from the core snap and files from the local repository.
The virtual machine is controlled with qemu monitor. A snapshot is taken
just after the machine reaches a stable state (as described by a
particular point in the /init script). Each test commences by
instructing the virtual machine monitor to revert to that snapshot.
Overall performance is excellent, with latency of 1st boot at around two
seconds and latency of snapshot restore close being immeasurable.

Certain amount of shell-level mocking is employed so that function-level
unit tests are possible. Mocking allows replacing shell built-ins and
external programs (such as mount) on a per-test basis. All of this is
under the control of a particular test developer.

Testing is only supported on x86_64 (but can be extended to x86) but
since all of the scripts are written in shell this is not an obstacle.
Testing on other platforms is primarily limited by lack of a
standardized kernel.

Currently only several functions of "scripts/ubuntu-core-functions" are
tested but the primary intent of this patch is to land the framework and
open the avenue for writing further tests.

Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com

[ogra1]

this is awesome !

one small nitpick on the design though ... is it actually necessary to completely replace the existing /init ?
how about you call the C program "test-init" or some such, boot the VM with init=/test-init and have it also re-exec the actual /init script in a wrapped way.
while it is cool to test the single script functions it doesnt help much if they are not invoked in the environment and context that /init provides ...

the builtin dependency system of the initrd scripts ($PREREQ) as well as the different exec stages (top/premount/mount/bottom) which can cause completely different environments should be involved in the testing as well.