qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autotest (was Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] C


From: Anthony Liguori
Subject: Re: autotest (was Re: [Qemu-devel] Re: [Qemu-commits] [COMMIT f80f9ec] Convert machine registration to use module initfunctions)
Date: Tue, 26 May 2009 04:30:00 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

Dor Laor wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Autotest doesn't currently test the regressions that I want to test.

Which regressions do you want to test?

For instance, we often have networking regressions. In particular, with the refactoring going on in slirp and tun/tap, I'd really like to have an automated way to test slirp and tap with TCP transmit/receive, and slirp redir. I have something locally to do this that I intend on posting in the next few days.

Current kvm autotest do test slirp. The step-files for guest installation open ssh/telnet access in order
to let the host reach them.
We trapped exactly this regression using autotest.

What I want is a single test that completes quickly. This means a preconfigured guest that I can run a quick test case against.

Installation tests a lot of things.  I'm looking for more targeted tests.

I wouldn't require kvm-autotest, but I'd like to have an interest set of unit tests that are then usable within kvm-autotest. Once we have that, asking politely for tests to be written I think is quite reasonable.
Some features are easily tested using a large framework, for example migration, slirp, time drift, etc. In addition kvm's tests unit tests, qemu-io and similar should be written too in order to test various cases that
are only reasonable to be found using low level operations.
No doubt all of the unit tests should be executed from autotest.

Yup, I agree 100%.

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]