[Top][All Lists]

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

Re: [Qemu-block] [PATCH v2 6/6] iotest 201: new test for qmp nbd-server-

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v2 6/6] iotest 201: new test for qmp nbd-server-remove
Date: Mon, 15 Jan 2018 09:05:24 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 01/15/2018 08:40 AM, Vladimir Sementsov-Ogievskiy wrote:

>> And the list archives show several threads of people complaining that
>> ./check failing with a diff that merely shows:
>> -.....
>> +..E..
> didn't see that. usually, for failed iotests I see
> -.....
> +..E..
> + some kind of assert-fail in one of testcases

Although deciphering the assert-fail is not always trivial, and it is
still sorely underdocumented on how to manually reproduce the situation
that got to the stackdump.

> so we know in which testcase and in which line it was failed.
>> makes it rather hard to see WHAT test 2 was doing that caused an error
>> instead of a pass, let alone set up a reproduction scenario on JUST the
>> failing test.  Yes, a lot of existing iotests use this unittest layout,
>> and on that grounds, I'm not opposed to adding another one; but test 194
>> really IS easier to debug when something goes wrong.
>>> And there 3 test cases, sharing same setUp. Do not you say that unittest
>>> becomes
>>> deprecated in qemu? I think, if we have only one testcase, we may use
>>> 194-like approach,
>>> but if we have more, it's better to use unittest.
>> Yes, I think a nice goal for improved testing is to write more
>> python-based iotests in the style that uses actual output, and not just
>> the unittest framework, in the test log.  It's not a hard requirement as
>> long as no one has converted existing tests, but is food for thought.
> I think, it doesn't mean that we should not use unittest at all, we just
> need more output with
> it.

Yes, that's also a potentially viable option.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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