qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, thuth@redhat.com,
	alex.bennee@linaro.org, f4bug@amsat.org, mreitz@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] docs: Add docs/devel/testing.rst
Date: Wed, 31 Jan 2018 14:49:42 +0100	[thread overview]
Message-ID: <20180131134942.a2cupkloo4cp33bc@kamzik.brq.redhat.com> (raw)
In-Reply-To: <20180131032800.25578-1-famz@redhat.com>

On Wed, Jan 31, 2018 at 11:28:00AM +0800, Fam Zheng wrote:
> To make our efforts on QEMU testing easier to consume by contributors,
> let's add a document. For example, Patchew reports build errors on
> patches that should be relatively easy to reproduce with a few steps, and
> it is much nicer if there is such a documentation that it can refer to.
> 
> This focuses on how to run existing tests and how to write new test
> cases, without going into the frameworks themselves.
> 
> The VM based testing section is moved from tests/vm/README which now
> is a single line pointing to the new doc.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> 
> ---
> 
> v2: Fix spelling errors and improve wordings. [Stefan, Eric, Thomas]
>     Example test name "test-foo -> foo-test". The mass renaming will be
>     done in another series. [Thomas, Eric]
>     Document how to debug unit tests and qtests. [Eric]
>     Document group permission setup for docker, and the privilege risks.
>     [Alex]
>     Update tests/vm/README.
> ---
>  docs/devel/testing.rst | 486 +++++++++++++++++++++++++++++++++++++++++++++++++
>  tests/vm/README        |  90 +--------
>  2 files changed, 487 insertions(+), 89 deletions(-)
>  create mode 100644 docs/devel/testing.rst
> 
> diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
> new file mode 100644
> index 0000000000..795df60dcd
> --- /dev/null
> +++ b/docs/devel/testing.rst
> @@ -0,0 +1,486 @@
> +===============
> +Testing in QEMU
> +===============
> +
> +This document describes the testing infrastructure in QEMU.
> +
> +Testing with "make check"
> +=========================
> +
> +The "make check" testing family includes most of the C based tests in QEMU. For
> +a quick help, run ``make check-help`` from the source tree.
> +
> +The usual way to run these tests is:
> +
> +.. code::
> +
> +  make check
> +
> +which includes QAPI schema tests, unit tests, and QTests. Different sub-types
> +of "make check" testings will be explained below.
> +
> +Before running tests, it is best to build QEMU programs first. Some tests
> +expect the executables to exist and will fail with obscure messages if they
> +cannot find them.
> +
> +Unit tests
> +----------
> +
> +Unit tests, which can be invoked with ``make check-unit``, are simple C tests
> +that typically link to individual QEMU object files and exercise them by
> +calling exported functions.
> +
> +If you are writing new code in QEMU, consider adding a unit test, especially
> +for utility modules that are relatively stateless or have few dependencies. To
> +add a new unit test:
> +
> +1. Create a new source file. For example, ``tests/foo-test.c``.
> +
> +2. Write the test. Normally you would include the header file which exports
> +   the module API, then verify the interface behaves as expected from your
> +   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. Optionally, you can add a magical variable to support ``gcov``.
> +   For example:
> +
> +.. code::
> +
> +  check-unit-y += tests/foo-test$(EXESUF)
> +  tests/foo-test$(EXESUF): tests/foo-test.o $(test-util-obj-y)
> +  ...
> +  gcov-files-foo-test-y = util/foo.c
> +
> +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
> +``gdb``. However there can still be differences in behavior between ``make``
> +invocations and your manual run, due to ``$MALLOC_PERTURB_`` environment
> +variable (which affects memory reclaimation and catches invalid pointers
> +better) and gtester options. If necessary, you can run
> +
> +.. code::
> +  make check-unit V=1
> +
> +and copy the actual command line which executes the unit test, then run
> +it from the command line.
> +
> +QTest
> +-----
> +
> +QTest is a device emulation testing framework.  It can be very useful to test
> +device models; it could also control certain aspects of QEMU (such as virtual
> +clock stepping), with a special purpose "qtest" protocol.  Refer to the
> +documentation in ``qtest.c`` for more details of the protocol.
> +
> +QTest cases can be executed with
> +
> +.. code::
> +
> +   make check-qtest
> +
> +The QTest library is implemented by ``tests/libqtest.c`` and the API is defined
> +in ``tests/libqtest.h``.
> +
> +Consider adding a new QTest case when you are introducing a new virtual
> +hardware, or extending one if you are adding functionalities to an existing
> +virtual device.
> +
> +On top of libqtest, a higher level library, ``libqos``, was created to
> +encapsulate common tasks of device drivers, such as memory management and
> +communicating with system buses or devices. Many virtual device tests use
> +libqos instead of directly calling into libqos.
                                           ^^ libqtest?

Thanks,
drew

  parent reply	other threads:[~2018-01-31 13:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31  3:28 [Qemu-devel] [PATCH v2] docs: Add docs/devel/testing.rst Fam Zheng
2018-01-31 13:45 ` Stefan Hajnoczi
2018-01-31 13:49 ` Andrew Jones [this message]
2018-02-01  0:26   ` Fam Zheng
2018-01-31 14:24 ` Eric Blake
2018-02-01  2:16   ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180131134942.a2cupkloo4cp33bc@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).