docs/devel: update instruction on how to add new unit tests

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
Paolo Bonzini 2020-10-06 08:49:55 -04:00
parent da00d067ea
commit bab88ead6f
2 changed files with 27 additions and 14 deletions

View File

@ -33,15 +33,27 @@ Steps to add a new QTest case are:
2. Write the test code with the glib and libqtest/libqos API. See also existing 2. Write the test code with the glib and libqtest/libqos API. See also existing
tests and the library headers for reference. tests and the library headers for reference.
3. Register the new test in ``tests/qtest/Makefile.include``. Add the test 3. Register the new test in ``tests/qtest/meson.build``. Add the test
executable name to an appropriate ``check-qtest-*-y`` variable. For example: executable name to an appropriate ``qtests_*`` variable. There is
one variable per architecture, plus ``qtests_generic`` for tests
that can be run for all architectures. For example::
``check-qtest-generic-y = tests/qtest/foo-test$(EXESUF)`` qtests_generic = [
...
'foo-test',
...
]
4. Add object dependencies of the executable in the Makefile, including the 4. If the test has more than one source file or needs to be linked with any
test source file(s) and other interesting objects. For example: dependency other than ``qemuutil`` and ``qos``, list them in the ``qtests``
dictionary. For example a test that needs to use the ``QIO`` library
will have an entry like::
``tests/qtest/foo-test$(EXESUF): tests/qtest/foo-test.o $(libqos-obj-y)`` {
...
'foo-test': [io],
...
}
Debugging a QTest failure is slightly harder than the unit test because the Debugging a QTest failure is slightly harder than the unit test because the
tests look up QEMU program names in the environment variables, such as tests look up QEMU program names in the environment variables, such as

View File

@ -41,15 +41,16 @@ add a new unit test:
test. The test code should be organized with the glib testing framework. test. The test code should be organized with the glib testing framework.
Copying and modifying an existing test is usually a good idea. Copying and modifying an existing test is usually a good idea.
3. Add the test to ``tests/Makefile.include``. First, name the unit test 3. Add the test to ``tests/meson.build``. The unit tests are listed in a
program and add it to ``$(check-unit-y)``; then add a rule to build the dictionary called ``tests``. The values are any additional sources and
executable. For example: dependencies to be linked with the test. For a simple test whose source
is in ``tests/foo-test.c``, it is enough to add an entry like::
.. code:: {
...
check-unit-y += tests/foo-test$(EXESUF) 'foo-test': [],
tests/foo-test$(EXESUF): tests/foo-test.o $(test-util-obj-y) ...
... }
Since unit tests don't require environment variables, the simplest way to debug Since unit tests don't require environment variables, the simplest way to debug
a unit test failure is often directly invoking it or even running it under a unit test failure is often directly invoking it or even running it under