Re: [Qemu-devel] [PATCH 2/2] tests: Add tmp105 unit test

["Andreas Färber" <afaerber@suse.de>]

Am 12.12.2012 15:44, schrieb Alex Horn:
> Thanks so much for taking the initiative on creating functional tests
> for the TMP105 hardware model. I am exciting to see these changes and
> I am wondering if your QTests could be complemented with the following
> standalone unit tests:
> 
>   https://github.com/ahorn/benchmarks/blob/965e571d92e677e8e64ad5faa0107f5dbd451981/qemu-hw/tmp105/tmp105-test.c

Honestly I consider that test a gross hack for three reasons:
* You ignore any global state that devices may rely on, i.e. some
operations like hotplug may succeed that would normally fail.
* You completely bypass QOM/qdev infrastructure by instantiating random
structs on the stack. This may lead to devices not properly being
initialized.
* You ignore any endianness swizzling our Memory API takes care of. (Did
you verify your tests on a Big Endian host?)

All this would be quite a lot of work to duplicate into a testing
environment and it occasionally changes, which is why we are reusing the
"original" infrastructure for testing in a special "qtest" mode.

What would be appreciated though is if you could add some of your tests
to our test infrastructure as a follow-up to my patches - assuming my
proposal gets adopted. For testing the alarm, Paolo's IRQs interception
API may be useful (in rtc-test IIRC).

> Their purpose is similar to yours except that unit tests focus on
> checking the internal state of a hardware model without requiring a
> bus implementation or a socket connection for the QTest client-server
> infrastructure. That is, unit tests do not seek to replace QTests but
> strengthen them (see also below).

I am the wrong person to argue about this, Anthony has been setting up
this test infrastructure. Unlike C++ with its friend classes we can't
test any static C functions anyway, so the interface for testing the way
you propose is very limited.

What I have been demonstrating is that it is too trivial to do it the
expected qtest way (one evening a prototype for bus+device plus one
evening a bus abstraction) to try working around it. :)

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg