From: Fam Zheng <famz@redhat.com>
To: "Daniel P. Berrange" <berrange@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 19:16:52 +0800 [thread overview]
Message-ID: <20170727111652.GI5117@lemon.lan> (raw)
In-Reply-To: <20170727100958.GG2555@redhat.com>
On Thu, 07/27 11:09, Daniel P. Berrange wrote:
> 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.
Yes, and IMO it should be the default and recommended way.
>
> > 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).
Good point. Maybe we should extend the -d option of ./check for more log, if the
above "full output" still isn't enough.
Fam
next prev parent reply other threads:[~2017-07-27 11:17 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
2017-07-27 11:16 ` Fam Zheng [this message]
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=20170727111652.GI5117@lemon.lan \
--to=famz@redhat.com \
--cc=apahim@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=cleber@redhat.com \
--cc=crosa@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).