On Mon, Jul 23, 2012 at 07:44:44PM +0000, Blue Swirl wrote:
On Mon, Jul 23, 2012 at 7:28 PM, Eduardo Habkost ehabkost@redhat.com wrote:
On Mon, Jul 23, 2012 at 07:11:11PM +0000, Blue Swirl wrote:
On Mon, Jul 23, 2012 at 6:59 PM, Eduardo Habkost ehabkost@redhat.com wrote:
On Mon, Jul 23, 2012 at 04:49:07PM +0000, Blue Swirl wrote:
On Mon, Jul 16, 2012 at 5:42 PM, Eduardo Habkost ehabkost@redhat.com wrote:
On Sat, Jul 14, 2012 at 09:14:30AM +0000, Blue Swirl wrote: [...] > >> > diff --git a/tests/Makefile b/tests/Makefile > >> > index b605e14..89bd890 100644 > >> > --- a/tests/Makefile > >> > +++ b/tests/Makefile > >> > @@ -15,6 +15,7 @@ check-unit-y += tests/test-string-output-visitor$(EXESUF) > >> > check-unit-y += tests/test-coroutine$(EXESUF) > >> > check-unit-y += tests/test-visitor-serialization$(EXESUF) > >> > check-unit-y += tests/test-iov$(EXESUF) > >> > +check-unit-y += tests/test-x86-cpuid$(EXESUF) > >> > >> This probably tries to build the cpuid test also for non-x86 targets > >> and break them all. > > > > I don't think there's any concept of "targets" for the check-unit tests. > > How about: > check-qtest-i386-y = tests/test-x86-cpuid$(EXESUF)
test-x86-cpuid is not a qtest test case.
Why not? I don't think it is a unit test either, judging from what the other unit tests do.
It is absolutely a unit test. I don't know why you don't think so. It simply checks the results of the APIC ID calculation functions.
Yes, but the other 'unit tests' (the names used here are very confusing, btw) check supporting functions like coroutines, not hardware. Hardware tests (qtest) need to bind to an architecture, in this case x86.
test-x86-cpuid doesn't check hardware, either. It just checks the simple functions that calculate APIC IDs (to make sure the math is correct). Those functions aren't even used by any hardware emulation code until later in the patch series (when the CPU initialization code gets changed to use the new function).
By that time the function is clearly x86 HW and the check is an x86 hardware check. QEMU as whole consists of simple functions that calculate something.
It's useful onily for a specific architecture, yes, but it surely doesn't make libqtest necessary.
That's the difference between the unit tests and qtest test cases: unit tests simply test small parts of the code (that may or may not be hardware-specific), and qtest tests hardware emulation after starting up a whole qemu process. It's a different kind of testing, with different sets of goals.
I suppose you are not arguing that no function inside target-* would be ever allowed to have a unit test written for it. That would be a very silly constraint for people writing tests.