= Automated testing of HelenOS in a virtual machine

Part of HelenOS [wiki:CI continuous testing] are also tests that are executed inside HelenOS. That is, we launch a VM (QEMU or MSIM at the moment) and check that command executed inside HelenOS gives the expected output. This page contains a brief overview of how to write such testing scenarios and how to run them.


== Prerequisites

For this to work, you need to have Python 3, QEMU, ImageMagick (i.e. `convert` command) and SED. For testing on mips32, you will also need MSIM, Xvfb (or Xephyr), xterm and xdotool.


== test-in-vm.py

The testing script is in the root of the [https://github.com/HelenOS/ci CI] repository. To try it, prepare a HelenOS image (or grab one from [http://ci.helenos.org/latest/ ci.helenos.org]) for one of the supported architectures. Here, we will assume you have downloaded [http://ci.helenos.org/latest/amd64/helenos-amd64-with-binutils-pcc.iso HelenOS with binutils and PCC for amd64] into `helenos-amd64-with-binutils-pcc.iso` into clone of CI repository.

For this image, we choose to run a scenario where we compile and run a Hello, World! program written in C. Scenarios are located under `scenarios` folder in CI repository, their format will be described later on.

To actually run the scenario, we launch the `test-in-vm.py` script and specify path to the boot image, architecture and path to the scenario. Advanced options will be described later.

{{{
./test-in-vm.py \
    --arch amd64 \
    --image helenos-amd64-with-binutils-pcc.iso \
    --scenario scenarios/coast/pcc/hello.yml
}}}

When you run this script, you will see that it starts QEMU with HelenOS and waits until the terminal appears. Then it automatically types commands that compiles `hello.c` and launches the compiled `a.out` binary. QEMU is then terminated and if all went okay, we will see a message about successful pass of the scenario (or error message explaining the reason for failure).

The use described in the paragraphs above is the basic usage. Usually, we would like to run the scenario without actual QEMU window (as not to distract us) and maybe dump all the contents of the terminal session. Switches for just right that are here:

 `--headless`:: Hides any windows, i.e. we can run the script on background or on CI server.
 `--memory MB`:: Change the amount of memory available to the virtual machine.
 `--pass OPTION`:: Extra options to pass through to the emulator (can be specified multiple times).
 `--vterm-dump FILENAME.txt`:: Where to store dump of the whole terminal session.
 `--last-screenshot FILENAME.png`:: Where to store screenshot just before the VM is terminated.
 `--debug`:: Prints (a lot of) debugging messages.


== Scenario files

The scenario file is stored in YAML format and has rather simple structure that is best described on example. We will again use the example from above where the scenario compiles a simple C program.

{{{#!yaml
meta:
  name: "Hello from PCC"
  harbours:
    - pcc
    - binutils

tasks:
  - boot
  - command:
      args: "cp /src/c/demos/hello/hello.c /tmp/hello.c"
  - command:
      args: "cd /tmp"
  - command:
      args: "pcc hello.c"
  - command:
      args: "./a.out"
      assert: "hello!"
}}}

The part `meta` has one mandatory item: `name` should briefly describe the scenario. This text is also used in CI output. `harbours` key is used solely by CI script and lists packages that has to be part of the image. If you run `test-in-vm.py` manually, it is your responsibility to prepare the right image!

The actual testing scenario is a list of tasks that are executed one after another. And unless stated otherwise, failure in one task aborts the whole run. The first task is always `boot` that simply waits for the machine to boot into userspace/GUI. The only other available task (so far) is `command` that executes single command in the terminal. `args` is the actual command and without any other arguments, the script only checks that the command has not ended with a failure (i.e. exit code 0).

To check that a specific string appears in the output of the command, one can use the `assert` key. If this string is not found in the output and the command terminates (i.e. the prompt reappears), the scenario is aborted. To check for a text that shall not appear (i.e. its appearance is a reason for abortion), use `negassert`. If we expect that the program would abort (i.e. we intentionally dereference NULL pointer etc.), we can add `ignoreabort: True` to skip checking the program exit code.

So far, the biggest scenario is `scenarios/base/fs.yml` that checks that it is possible to create FAT image inside HelenOS, mount it and write data to it. This scenario also uses `name` to better describe why we launch each command in the sequence. Use it as a good example for your own experimenting.