浏览代码

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

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini 4 年之前
父节点
当前提交
bab88ead6f
共有 2 个文件被更改,包括 31 次插入18 次删除
  1. 21 9
      docs/devel/qtest.rst
  2. 10 9
      docs/devel/testing.rst

+ 21 - 9
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
 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
-   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
 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

+ 10 - 9
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.
    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
-   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
 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