From: "Daniel P. Berrange" <berrange@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
"Lukáš Doktor" <ldoktor@redhat.com>,
"Cleber Rosa" <cleber@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
"Amador Pahim" <apahim@redhat.com>,
qemu-devel@nongnu.org, "Cleber Rosa" <crosa@redhat.com>
Subject: Re: [Qemu-devel] Improving QMP test coverage
Date: Thu, 27 Jul 2017 11:09:58 +0100 [thread overview]
Message-ID: <20170727100958.GG2555@redhat.com> (raw)
In-Reply-To: <20170727091957.GC5117@lemon.lan>
On Thu, Jul 27, 2017 at 05:19:57PM +0800, Fam Zheng wrote:
> On Thu, 07/27 10:14, Markus Armbruster wrote:
> > This brings some advantages of "verify output with diff" to tests that
> > verify with code. Improvement if it simplifies the verification code.
> >
> > I'd still prefer *no* verification code (by delegating the job to diff)
> > for tests where I can get away wit it.
>
> Python based iotests can be (re)done in such a way that they print actual logs
> (interactions with qtest/monitor, stdout/stderr of QEMU, etc) instead of the
> current dot dot dot summary, then we automatically have diff based verification,
> no?
The python test 149 that I wrote does exactly that. There's no reason why
the others couldn't do the same.
> One thing I feel painful with bash iotests is how harder it is to write
> complicated test scenarios such as migration, incremental backup, etc.
Yes, shell is an awful language if you need non-trivial control
logic or data structures
> On the other hand the iotests are more difficult to debug when things go wrong
> because it eats the output which, if done with shell, should be very easy to
> get.
Even if the python tests are not doing verify-by-diff, it should be fairly
easy to wire up an env variable IOTESTS_DEBUG=1 which would force them
to propagate stdout/err of all commands run (or at least save it to a
log file somewhere).
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:[~2017-07-27 10:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 15:28 [Qemu-devel] Improving QMP test coverage Markus Armbruster
2017-07-17 10:33 ` Stefan Hajnoczi
2017-07-18 16:24 ` Markus Armbruster
2017-07-21 15:33 ` Stefan Hajnoczi
2017-07-21 16:16 ` Cleber Rosa
2017-07-24 6:56 ` Markus Armbruster
2017-07-26 1:21 ` Cleber Rosa
2017-07-27 8:14 ` Markus Armbruster
2017-07-27 9:19 ` Fam Zheng
2017-07-27 9:58 ` Fam Zheng
2017-07-27 10:09 ` Daniel P. Berrange [this message]
2017-07-27 11:16 ` Fam Zheng
2017-08-01 10:25 ` Stefan Hajnoczi
2017-07-27 10:04 ` Daniel P. Berrange
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=20170727100958.GG2555@redhat.com \
--to=berrange@redhat.com \
--cc=apahim@redhat.com \
--cc=armbru@redhat.com \
--cc=cleber@redhat.com \
--cc=crosa@redhat.com \
--cc=famz@redhat.com \
--cc=ldoktor@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).