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
signature.asc
Description: OpenPGP digital signature
