diff options
| -rw-r--r-- | docs/devel/qtest.rst | 30 | ||||
| -rw-r--r-- | docs/devel/testing.rst | 19 |
2 files changed, 31 insertions, 18 deletions
diff --git a/docs/devel/qtest.rst b/docs/devel/qtest.rst index 075fe5f7d5..97c5a75626 100644 --- a/docs/devel/qtest.rst +++ b/docs/devel/qtest.rst @@ -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 tests and the library headers for reference. -3. Register the new test in ``tests/qtest/Makefile.include``. Add the test - executable name to an appropriate ``check-qtest-*-y`` variable. For example: - - ``check-qtest-generic-y = tests/qtest/foo-test$(EXESUF)`` - -4. Add object dependencies of the executable in the Makefile, including the - test source file(s) and other interesting objects. For example: - - ``tests/qtest/foo-test$(EXESUF): tests/qtest/foo-test.o $(libqos-obj-y)`` +3. Register the new test in ``tests/qtest/meson.build``. Add the test + 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:: + + qtests_generic = [ + ... + 'foo-test', + ... + ] + +4. If the test has more than one source file or needs to be linked with any + 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:: + + { + ... + 'foo-test': [io], + ... + } 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 diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst index e58389b29f..0c3e79d31c 100644 --- a/docs/devel/testing.rst +++ b/docs/devel/testing.rst @@ -41,15 +41,16 @@ add a new unit test: test. The test code should be organized with the glib testing framework. Copying and modifying an existing test is usually a good idea. -3. Add the test to ``tests/Makefile.include``. First, name the unit test - program and add it to ``$(check-unit-y)``; then add a rule to build the - executable. For example: - -.. code:: - - check-unit-y += tests/foo-test$(EXESUF) - tests/foo-test$(EXESUF): tests/foo-test.o $(test-util-obj-y) - ... +3. Add the test to ``tests/meson.build``. The unit tests are listed in a + dictionary called ``tests``. The values are any additional sources and + 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:: + + { + ... + 'foo-test': [], + ... + } 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 |