From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Octavian Purdila <tavip@google.com>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org, stefanst@google.com,
pbonzini@redhat.com, alex.bennee@linaro.org, thuth@redhat.com,
marcandre.lureau@redhat.com, alistair@alistair23.me,
philmd@linaro.org, jsnow@redhat.com, crosa@redhat.com,
bleal@redhat.com
Subject: Re: [RFC PATCH 00/23] NXP i.MX RT595, ARM SVD and device model unit tests
Date: Mon, 12 Aug 2024 17:22:43 +0100 [thread overview]
Message-ID: <Zro207XTHFILvRoe@redhat.com> (raw)
In-Reply-To: <CAFEAcA9tUW0DHHOuGJ4sUxu12JMLUMxqW=_9oUHKiiRTenZwKw@mail.gmail.com>
On Mon, Aug 12, 2024 at 05:10:52PM +0100, Peter Maydell wrote:
> On Mon, 5 Aug 2024 at 21:17, Octavian Purdila <tavip@google.com> wrote:
> > It also introduces unit tests for device models. To allow accessing
> > registers from unit tests a system bus mock is created. The main
> > advantage of unit tests for device models over QTest is that device
> > models can be tested in isolation and do not require a full qemu
> > machine.
>
> On the other hand the disadvantage is that you need to add a
> bunch of extra code to mock the interfaces that the device
> connects to, and then you compile into the test binary a
> subset of C files which weren't written with the expectation
> that they got compiled into tests like that, so it feels a
> bit brittle. The nice thing about qtest is that it doesn't
> need you to do any of that -- you just run the QEMU machine
> model and prod the devices it already has.
Yep, mocking often ends up being rather a double-edged sword.
You can do some really powerful things with it, and in particular
it can enable you test scenarios / code paths that are hard or
impractical to exercise with regular functional tests where fault
injection is difficult/impossible.
The cost of this though is that the mocks can pose a significant
ongoing maint burden on anyone who refactors code in future, as
the mocks need to evolve in lockstep with the code refactoring.
12 months down the line, it can be hard for another maintainer
to understand the full purpose of the mocks & thus even harder
to know what todo as they refactor the code. The future burden
of mocks rarely falls on the person who creates them in the
first place.
> Do you have examples in this series of tests which you
> were able to write with this unit test setup that you
> wouldn't have been able to write equivalents of with the
> qtest framework ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-08-12 16:24 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 20:16 [RFC PATCH 00/23] NXP i.MX RT595, ARM SVD and device model unit tests Octavian Purdila
2024-08-05 20:16 ` [RFC PATCH 01/23] fifo32: add peek function Octavian Purdila
2024-08-05 20:16 ` [RFC PATCH 02/23] tests/unit: add fifo test Octavian Purdila
2024-08-05 20:16 ` [RFC PATCH 03/23] scripts: add script to generate C header files from SVD XML files Octavian Purdila
2024-08-08 21:56 ` John Snow
2024-08-08 22:30 ` Octavian Purdila
2024-08-08 23:06 ` John Snow
2024-08-09 9:30 ` Philippe Mathieu-Daudé
2024-08-09 9:42 ` Paolo Bonzini
2024-08-09 9:59 ` Daniel P. Berrangé
2024-08-13 8:32 ` Philippe Mathieu-Daudé
2024-08-09 6:34 ` Paolo Bonzini
2024-08-09 19:28 ` Octavian Purdila
2024-08-12 15:27 ` Peter Maydell
2024-08-12 17:56 ` Octavian Purdila
2024-08-12 22:43 ` Richard Henderson
2024-08-13 15:47 ` Octavian Purdila
2024-08-05 20:16 ` [RFC PATCH 04/23] hw/arm: add SVD file for NXP i.MX RT595 Octavian Purdila
2024-08-06 14:06 ` Alex Bennée
2024-08-06 20:31 ` Octavian Purdila
2024-08-07 11:24 ` Philippe Mathieu-Daudé
2024-08-07 16:36 ` Octavian Purdila
2024-08-09 9:13 ` Daniel P. Berrangé
2024-08-09 22:40 ` Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 05/23] hw: add register access utility functions Octavian Purdila
2024-08-12 15:32 ` Peter Maydell
2024-08-12 21:14 ` Octavian Purdila
2024-08-12 22:35 ` Richard Henderson
2024-08-13 8:28 ` Philippe Mathieu-Daudé
2024-08-05 20:17 ` [RFC PATCH 06/23] hw/misc: add basic flexcomm device model Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 07/23] tests/unit: add system bus mock Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 08/23] test/unit: add register access macros and functions Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 09/23] test/unit: add flexcomm unit test Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 10/23] hw/char: add support for flexcomm usart Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 11/23] test/unit: add flexcomm usart unit test Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 12/23] hw/i2c: add support for flexcomm i2c Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 13/23] test/unit: add i2c-tester Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 14/23] test/unit: add unit tests for flexcomm i2c Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 15/23] hw/ssi: add support for flexcomm spi Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 16/23] test/unit: add spi-tester Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 17/23] test/unit: add unit tests for flexcomm spi Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 18/23] hw/misc: add support for RT500's clock controller Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 19/23] test/unit: add unit tests " Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 20/23] hw/ssi: add support for flexspi Octavian Purdila
2024-08-08 5:11 ` Philippe Mathieu-Daudé
2024-08-08 21:31 ` Octavian Purdila
2024-08-09 8:54 ` Philippe Mathieu-Daudé
2024-08-05 20:17 ` [RFC PATCH 21/23] hw/misc: add support for RT500 reset controller Octavian Purdila
2024-08-08 5:00 ` Philippe Mathieu-Daudé
2024-08-05 20:17 ` [RFC PATCH 22/23] hw/arm: add basic support for the RT500 SoC Octavian Purdila
2024-08-06 14:51 ` Philippe Mathieu-Daudé
2024-08-07 23:57 ` Octavian Purdila
2024-08-05 20:17 ` [RFC PATCH 23/23] hw/arm: add RT595-EVK board Octavian Purdila
2024-08-12 16:10 ` [RFC PATCH 00/23] NXP i.MX RT595, ARM SVD and device model unit tests Peter Maydell
2024-08-12 16:22 ` Daniel P. Berrangé [this message]
2024-08-12 18:39 ` Octavian Purdila
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=Zro207XTHFILvRoe@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alistair@alistair23.me \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=jsnow@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanst@google.com \
--cc=tavip@google.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).