Writing Tests¶
A NixOS test is a Nix expression that has the following structure:
import ./make-test-python.nix {
# Either the configuration of a single machine:
machine =
{ config, pkgs, ... }:
{ *configuration…*
};
# Or a set of machines:
nodes =
{ *machine1* =
{ config, pkgs, ... }: { *…* };
*machine2* =
{ config, pkgs, ... }: { *…* };
…
};
testScript =
''
*Python code…*
'';
}
The attribute testScript
is a bit of Python code that
executes the test (described below). During the test, it will start one or
more virtual machines, the configuration of which is described by the
attribute machine
(if you need only one machine in your
test) or by the attribute nodes
(if you need multiple
machines). For instance,
login.nix
only needs a single machine to test whether users can log in on the virtual
console, whether device ownership is correctly maintained when switching
between consoles, and so on. On the other hand,
nfs.nix,
which tests NFS client and server functionality in the Linux kernel
(including whether locks are maintained across server crashes), requires
three machines: a server and two clients.
There are a few special NixOS configuration options for test VMs:
virtualisation.memorySize¶
The memory of the VM in megabytes.
virtualisation.vlans¶
The virtual networks to which the VM is connected. See nat.nix for an example.
virtualisation.writableStore¶
By default, the Nix store in the VM is not writable. If you enable this option, a writable union file system is mounted on top of the Nix store to make it appear writable. This is necessary for tests that run Nix operations that modify the store.
For more options, see the module qemu-vm.nix.
The test script is a sequence of Python statements that perform various
actions, such as starting VMs, executing commands in the VMs, and so on. Each
virtual machine is represented as an object stored in the variable
*name*
if this is also the
identifier of the machine in the declarative config.
If you didn’t specify multiple machines using the nodes
attribute, it is just machine
.
The following example starts the machine, waits until it has finished booting,
then executes a command and checks that the output is more-or-less correct:
machine.start()
machine.wait_for_unit("default.target")
if not "Linux" in machine.succeed("uname"):
raise Exception("Wrong OS")
The first line is actually unnecessary; machines are implicitly started when
you first execute an action on them (such as wait_for_unit
or succeed
). If you have multiple machines, you can speed
up the test by starting them in parallel:
start_all()
The following methods are available on machine objects:
start
Start the virtual machine. This method is asynchronous — it does not wait for the machine to finish booting.
shutdown
Shut down the machine, waiting for the VM to exit.
crash
Simulate a sudden power failure, by telling the VM to exit immediately.
block
Simulate unplugging the Ethernet cable that connects the machine to the other machines.
unblock
Undo the effect of block.
screenshot
Take a picture of the display of the virtual machine, in PNG format. The screenshot is linked from the HTML log.
get_screen_text
Return a textual representation of what is currently visible on the machine’s screen using optical character recognition.
Note
This requires passing to the test attribute set.
send_monitor_command
Send a command to the QEMU monitor. This is rarely used, but allows doing stuff such as attaching virtual USB disks to a running machine.
send_keys
Simulate pressing keys on the virtual keyboard, e.g.,send_keys("ctrl-alt-delete")
.
send_chars
Simulate typing a sequence of characters on the virtual keyboard, e.g.,send_keys("foobar\\n")
will type the stringfoobar
followed by the Enter key.
execute
Execute a shell command, returning a list(*status*, *stdout*)
.
succeed
Execute a shell command, raising an exception if the exit status is not zero, otherwise returning the standard output.
fail
Like succeed, but raising an exception if the command returns a zero status.
wait_until_succeeds
Repeat a shell command with 1-second intervals until it succeeds.
wait_until_fails
Repeat a shell command with 1-second intervals until it fails.
wait_for_unit
Wait until the specified systemd unit has reached the “active” state.
wait_for_file
Wait until the specified file exists.
wait_for_open_port
Wait until a process is listening on the given TCP port (onlocalhost
, at least).
wait_for_closed_port
Wait until nobody is listening on the given TCP port.
wait_for_x
Wait until the X11 server is accepting connections.
wait_for_text
Wait until the supplied regular expressions matches the textual contents of the screen by using optical character recognition (see get_screen_text).
Note
This requires passing to the test attribute set.
wait_for_window
Wait until an X11 window has appeared whose name matches the given regular expression, e.g.,wait_for_window("Terminal")
.
copy_file_from_host
Copies a file from host to machine, e.g.,
copy_file_from_host("myfile", "/etc/my/important/file")
.The first argument is the file on the host. The file needs to be accessible while building the nix derivation. The second argument is the location of the file on the machine.
systemctl
Runs
systemctl
commands with optional support forsystemctl --user
machine.systemctl("list-jobs --no-pager") # runs `systemctl list-jobs --no-pager` machine.systemctl("list-jobs --no-pager", "any-user") # spawns a shell for `any-user` and runs `systemctl --user list-jobs --no-pager`
To test user units declared by systemd.user.services
the
optional user
argument can be used:
machine.start()
machine.wait_for_x()
machine.wait_for_unit("xautolock.service", "x-session-user")
This applies to systemctl
, get_unit_info
,
wait_for_unit
, start_job
and
stop_job
.
For faster dev cycles it’s also possible to disable the code-linters (this shouldn’t be commited though):
import ./make-test-python.nix {
skipLint = true;
machine =
{ config, pkgs, ... }:
{ *configuration…*
};
testScript =
''
*Python code…*
'';
}