From e1a1146690736c106c047be9e5ab246e3b9f306b Mon Sep 17 00:00:00 2001 From: Eelco Dolstra Date: Mon, 14 Apr 2014 19:07:35 +0200 Subject: [PATCH] Update section on writing tests --- nixos/doc/manual/development.xml | 389 +++++++++++++++++++++++-------- nixos/doc/manual/manual.xml | 2 +- 2 files changed, 296 insertions(+), 95 deletions(-) diff --git a/nixos/doc/manual/development.xml b/nixos/doc/manual/development.xml index 88f3dc0d9c13..a93b4b163bd5 100644 --- a/nixos/doc/manual/development.xml +++ b/nixos/doc/manual/development.xml @@ -1,5 +1,6 @@ + xmlns:xlink="http://www.w3.org/1999/xlink" + xml:id="ch-development"> Development @@ -9,7 +10,7 @@ NixOS. -
+
Getting the sources @@ -74,7 +75,7 @@ in nixos/ as packages. -
+
Writing NixOS modules @@ -579,7 +580,7 @@ systemd.services.dhcpcd = -
+
Building specific parts of NixOS @@ -692,7 +693,7 @@ $ systemctl start tmp-httpd.service -
+
Building your own NixOS CD @@ -748,57 +749,310 @@ $ ./result/bin/nixos-install -
Whole-system testing using virtual machines +
-Complete NixOS GNU/Linux systems can be tested in virtual -machines (VMs). This makes it possible to test a system upgrade or -configuration change before rebooting into it, using the -nixos-rebuild build-vm or nixos-rebuild -build-vm-with-bootloader command. +NixOS tests - -The tests/ directory in the NixOS source -tree contains several whole-system unit tests. -These tests can be runNixOS tests can be run both from -NixOS and from a non-NixOS GNU/Linux distribution, provided the Nix -package manager is installed. from the NixOS source -tree as follows: +When you add some feature to NixOS, you should write a test for +it. NixOS tests are kept in the directory nixos/tests, +and are executed (using Nix) by a testing framework that automatically +starts one or more virtual machines containing the NixOS system(s) +required for the test. + +Writing tests + +A NixOS test is a Nix expression that has the following structure: + + +import ./make-test.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 = + '' + Perl code… + ''; +} + + +The attribute testScript is a bit of Perl 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: + + + + + + + + The memory of the VM in + megabytes. + + + + + The virtual networks to which the VM is + connected. See nat.nix + for an example. + + + + + 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 Perl 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, +where name is the identifier of the machine +(which is just machine if you didn’t specify +multiple machines using the nodes attribute). For +instance, the following 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->waitForUnit("default.target"); +$machine->succeed("uname") =~ /Linux/; + + +The first line is actually unnecessary; machines are implicitly +started when you first execute an action on them (such as +waitForUnit or succeed). If you +have multiple machines, you can speed up the test by starting them in +parallel: + + +startAll; + + + + +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. + + + + sendMonitorCommand + 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. + + + + sendKeys + Simulate pressing keys on the virtual keyboard, + e.g., sendKeys("ctrl-alt-delete"). + + + + sendChars + Simulate typing a sequence of characters on the + virtual keyboard, e.g., sendKeys("foobar\n") + will type the string foobar 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. + + + + waitUntilSucceeds + Repeat a shell command with 1-second intervals + until it succeeds. + + + + waitUntilFails + Repeat a shell command with 1-second intervals + until it fails. + + + + waitForUnit + Wait until the specified systemd unit has reached + the “active” state. + + + + waitForFile + Wait until the specified file + exists. + + + + waitForOpenPort + Wait until a process is listening on the given TCP + port (on localhost, at least). + + + + waitForClosedPort + Wait until nobody is listening on the given TCP + port. + + + + waitForX + Wait until the X11 server is accepting + connections. + + + + waitForWindow + Wait until an X11 window has appeared whose name + matches the given regular expression, e.g., + waitForWindow(qr/Terminal/). + + + + + + + + + +Running tests + +You can run tests using nix-build. For +example, to run the test login.nix, +you just do: -$ nix-build tests/ -A nfs.test +$ nix-build '<nixpkgs/nixos/tests/login.nix>' -This performs an automated test of the NFS client and server -functionality in the Linux kernel, including file locking semantics -(e.g., whether locks are maintained across server crashes). It will -first build or download all the dependencies of the test (e.g., all -packages needed to run a NixOS VM). The test is defined in -tests/nfs.nix. If the test succeeds, -nix-build will place a symlink -./result in the current directory pointing at the -location in the Nix store of the test results (e.g., screenshots, test -reports, and so on). In particular, a pretty-printed log of the test -is written to log.html, which can be viewed using -a web browser like this: +or, if you don’t want to rely on NIX_PATH: + + +$ cd /my/nixpkgs/nixos/tests +$ nix-build login.nix +… +running the VM test script +machine: QEMU running (pid 8841) +… +6 out of 6 tests succeeded + + +After building/downloading all required dependencies, this will +perform a build that starts a QEMU/KVM virtual machine containing a +NixOS system. The virtual machine mounts the Nix store of the host; +this makes VM creation very fast, as no disk image needs to be +created. Afterwards, you can view a pretty-printed log of the test: $ firefox result/log.html + It is also possible to run the test environment interactively, allowing you to experiment with the VMs. For example: -$ nix-build tests/ -A nfs.driver +$ nix-build login.nix -A driver $ ./result/bin/nixos-run-vms -The script nixos-run-vms starts the three virtual -machines defined in the NFS test using QEMU/KVM. The root file system -of the VMs is created on the fly and kept across VM restarts in +The script nixos-run-vms starts the virtual +machines defined by test. The root file system of the VMs is created +on the fly and kept across VM restarts in ./hostname.qcow2. Finally, the test itself can be run interactively. This is @@ -811,17 +1065,11 @@ starting VDE switch for network 1 > -Perl statements can now be typed in to start or manipulate the VMs: +You can then take any Perl statement, e.g. -> startAll; -(the VMs start booting) -> $server->waitForJob("nfs-kernel-nfsd"); -> $client1->succeed("flock -x /data/lock -c 'sleep 100000' &"); -> $client2->fail("flock -n -s /data/lock true"); -> $client1->shutdown; -(this releases client1's lock) -> $client2->succeed("flock -n -s /data/lock true"); +> startAll +> $machine->succeed("touch /tmp/foo") The function testScript executes the entire test @@ -829,54 +1077,7 @@ script and drops you back into the test driver command line upon its completion. This allows you to inspect the state of the VMs after the test (e.g. to debug the test script). -This and other tests are continuously run on the Hydra -instance at nixos.org, which allows -developers to be notified of any regressions introduced by a NixOS or -Nixpkgs change. - -The actual Nix programming interface to VM testing is in NixOS, -under -lib/testing.nix. This file defines a -function which takes an attribute set containing a -nixpkgs attribute (the path to a Nixpkgs checkout), -and a system attribute (the system type). It -returns an attribute set containing several utility functions, among -which the main entry point is makeTest. - - -The makeTest function takes a function -similar to that found in -tests/nfs.nix (discussed above). It -returns an attribute set containing (among others): - - - - - test - A derivation containing the test log as an HTML - file, as seen above, suitable for presentation in the Hydra - continuous build system. - - - - report - A derivation containing a code coverage report, with - meta-data suitable for Hydra. - - - - driver - A derivation containing scripts to run the VM test or - interact with the VM network interactively, as seen above. - - - - - - +
diff --git a/nixos/doc/manual/manual.xml b/nixos/doc/manual/manual.xml index 5753a8ff9e74..8d7c28dee733 100644 --- a/nixos/doc/manual/manual.xml +++ b/nixos/doc/manual/manual.xml @@ -60,7 +60,7 @@ - List of options + Configuration options