From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjvnW-0001ls-Hl for qemu-devel@nongnu.org; Sat, 15 Dec 2012 12:45:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjvnV-0006uB-Cp for qemu-devel@nongnu.org; Sat, 15 Dec 2012 12:45:14 -0500 Received: from cantor2.suse.de ([195.135.220.15]:53748 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjvnV-0006tv-3T for qemu-devel@nongnu.org; Sat, 15 Dec 2012 12:45:13 -0500 Message-ID: <50CCB71B.4020205@suse.de> Date: Sat, 15 Dec 2012 18:44:59 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1355293773-18361-1-git-send-email-andreas.faerber@web.de> <1355293773-18361-3-git-send-email-andreas.faerber@web.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] tests: Add tmp105 unit test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Horn Cc: Peter Maydell , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Paolo Bonzini 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: >=20 > https://github.com/ahorn/benchmarks/blob/965e571d92e677e8e64ad5faa010= 7f5dbd451981/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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg