mirror of
https://github.com/ilyakooo0/nixpkgs.git
synced 2024-12-28 14:22:50 +03:00
235c2228ca
Basically, this creates a screenshot and throws tesseract at it to recognize the characters from the screenshot. In order to produce a result that is well enough, we're using lanczos scaling and scale the image up to 400% of its original size. This provides the base functionality for a new Machine method which will be called waitForText. I originally had that idea long ago when writing the VM tests for VirtualBox and Chromium, but thought it would be disproportionate to the case. The downside however is that VM tests now depend on tesseract, but given the average runtime of our tests it really shouldn't have a too big impact and it's only a runtime dependency after all. Another issue is that the OCR process takes quite some time to finish, but IMHO it's better (as in more deterministic) than to rely on sleep(). Signed-off-by: aszlig <aszlig@redmoonstudios.org>
258 lines
8.9 KiB
XML
258 lines
8.9 KiB
XML
<section xmlns="http://docbook.org/ns/docbook"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||
version="5.0"
|
||
xml:id="sec-writing-nixos-tests">
|
||
|
||
<title>Writing Tests</title>
|
||
|
||
<para>A NixOS test is a Nix expression that has the following structure:
|
||
|
||
<programlisting>
|
||
import ./make-test.nix {
|
||
|
||
# Either the configuration of a single machine:
|
||
machine =
|
||
{ config, pkgs, ... }:
|
||
{ <replaceable>configuration…</replaceable>
|
||
};
|
||
|
||
# Or a set of machines:
|
||
nodes =
|
||
{ <replaceable>machine1</replaceable> =
|
||
{ config, pkgs, ... }: { <replaceable>…</replaceable> };
|
||
<replaceable>machine2</replaceable> =
|
||
{ config, pkgs, ... }: { <replaceable>…</replaceable> };
|
||
…
|
||
};
|
||
|
||
testScript =
|
||
''
|
||
<replaceable>Perl code…</replaceable>
|
||
'';
|
||
}
|
||
</programlisting>
|
||
|
||
The attribute <literal>testScript</literal> 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 <literal>machine</literal> (if you need only one
|
||
machine in your test) or by the attribute <literal>nodes</literal> (if
|
||
you need multiple machines). For instance, <filename
|
||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/login.nix">login.nix</filename>
|
||
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, <filename
|
||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nfs.nix">nfs.nix</filename>,
|
||
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.</para>
|
||
|
||
<para>There are a few special NixOS configuration options for test
|
||
VMs:
|
||
|
||
<!-- FIXME: would be nice to generate this automatically. -->
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><option>virtualisation.memorySize</option></term>
|
||
<listitem><para>The memory of the VM in
|
||
megabytes.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><option>virtualisation.vlans</option></term>
|
||
<listitem><para>The virtual networks to which the VM is
|
||
connected. See <filename
|
||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/nat.nix">nat.nix</filename>
|
||
for an example.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><option>virtualisation.writableStore</option></term>
|
||
<listitem><para>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.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
|
||
For more options, see the module <filename
|
||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/qemu-vm.nix">qemu-vm.nix</filename>.</para>
|
||
|
||
<para>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 <literal>$<replaceable>name</replaceable></literal>,
|
||
where <replaceable>name</replaceable> is the identifier of the machine
|
||
(which is just <literal>machine</literal> if you didn’t specify
|
||
multiple machines using the <literal>nodes</literal> 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:
|
||
|
||
<programlisting>
|
||
$machine->start;
|
||
$machine->waitForUnit("default.target");
|
||
$machine->succeed("uname") =~ /Linux/;
|
||
</programlisting>
|
||
|
||
The first line is actually unnecessary; machines are implicitly
|
||
started when you first execute an action on them (such as
|
||
<literal>waitForUnit</literal> or <literal>succeed</literal>). If you
|
||
have multiple machines, you can speed up the test by starting them in
|
||
parallel:
|
||
|
||
<programlisting>
|
||
startAll;
|
||
</programlisting>
|
||
|
||
</para>
|
||
|
||
<para>The following methods are available on machine objects:
|
||
|
||
<variablelist>
|
||
|
||
<varlistentry>
|
||
<term><methodname>start</methodname></term>
|
||
<listitem><para>Start the virtual machine. This method is
|
||
asynchronous — it does not wait for the machine to finish
|
||
booting.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>shutdown</methodname></term>
|
||
<listitem><para>Shut down the machine, waiting for the VM to
|
||
exit.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>crash</methodname></term>
|
||
<listitem><para>Simulate a sudden power failure, by telling the VM
|
||
to exit immediately.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>block</methodname></term>
|
||
<listitem><para>Simulate unplugging the Ethernet cable that
|
||
connects the machine to the other machines.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>unblock</methodname></term>
|
||
<listitem><para>Undo the effect of
|
||
<methodname>block</methodname>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>screenshot</methodname></term>
|
||
<listitem><para>Take a picture of the display of the virtual
|
||
machine, in PNG format. The screenshot is linked from the HTML
|
||
log.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>getScreenText</methodname></term>
|
||
<listitem><para>Return a textual representation of what is currently
|
||
visible on the machine's screen using optical character
|
||
recognition.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>sendMonitorCommand</methodname></term>
|
||
<listitem><para>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.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>sendKeys</methodname></term>
|
||
<listitem><para>Simulate pressing keys on the virtual keyboard,
|
||
e.g., <literal>sendKeys("ctrl-alt-delete")</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>sendChars</methodname></term>
|
||
<listitem><para>Simulate typing a sequence of characters on the
|
||
virtual keyboard, e.g., <literal>sendKeys("foobar\n")</literal>
|
||
will type the string <literal>foobar</literal> followed by the
|
||
Enter key.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>execute</methodname></term>
|
||
<listitem><para>Execute a shell command, returning a list
|
||
<literal>(<replaceable>status</replaceable>,
|
||
<replaceable>stdout</replaceable>)</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>succeed</methodname></term>
|
||
<listitem><para>Execute a shell command, raising an exception if
|
||
the exit status is not zero, otherwise returning the standard
|
||
output.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>fail</methodname></term>
|
||
<listitem><para>Like <methodname>succeed</methodname>, but raising
|
||
an exception if the command returns a zero status.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitUntilSucceeds</methodname></term>
|
||
<listitem><para>Repeat a shell command with 1-second intervals
|
||
until it succeeds.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitUntilFails</methodname></term>
|
||
<listitem><para>Repeat a shell command with 1-second intervals
|
||
until it fails.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForUnit</methodname></term>
|
||
<listitem><para>Wait until the specified systemd unit has reached
|
||
the “active” state.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForFile</methodname></term>
|
||
<listitem><para>Wait until the specified file
|
||
exists.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForOpenPort</methodname></term>
|
||
<listitem><para>Wait until a process is listening on the given TCP
|
||
port (on <literal>localhost</literal>, at least).</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForClosedPort</methodname></term>
|
||
<listitem><para>Wait until nobody is listening on the given TCP
|
||
port.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForX</methodname></term>
|
||
<listitem><para>Wait until the X11 server is accepting
|
||
connections.</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><methodname>waitForWindow</methodname></term>
|
||
<listitem><para>Wait until an X11 window has appeared whose name
|
||
matches the given regular expression, e.g.,
|
||
<literal>waitForWindow(qr/Terminal/)</literal>.</para></listitem>
|
||
</varlistentry>
|
||
|
||
</variablelist>
|
||
|
||
</para>
|
||
|
||
</section> |