On 07/25/2017 11:49 AM, Stefan Hajnoczi wrote: > On Fri, Jul 21, 2017 at 10:21:24AM -0400, Cleber Rosa wrote: >> On 07/21/2017 10:01 AM, Daniel P. Berrange wrote: >>> On Fri, Jul 21, 2017 at 01:33:25PM +0100, Stefan Hajnoczi wrote: >>>> On Thu, Jul 20, 2017 at 11:47:27PM -0400, Cleber Rosa wrote: >> Without the static capabilities defined, the dynamic check would be >> influenced by the run time environment. It would really mean "qemu-io >> running on this environment (filesystem?) can do native aio". Again, >> that's not the best type of information to depend on when writing tests. > > Can you explain this more? > > It seems logical to me that if qemu-io in this environment cannot do > aio=native then we must skip those tests. > > Stefan >
OK, let's abstract a bit more. Let's take this part of your statement: "if qemu-io in this environment cannot do aio=native" Let's call that a feature check. Depending on how the *feature check* is written, a negative result may hide a test failure, because it would now be skipped. Suppose that a feature check for "SDL display" is such that you run "qemu -display sdl". A *feature failure* here (SDL init is broken), or an environment issue (DISPLAY=), will cause a SDL test skip. If you base the test skip decision to a simple lookup on a list of features (not calling them build configuration anymore, as this is clear not attractive), this won't happen. A "feature statement check" will make the test proceed, and the *failure* will be presented. I hope the pattern is visible. -- Cleber Rosa [ Sr Software Engineer - Virtualization Team - Red Hat ] [ Avocado Test Framework - avocado-framework.github.io ] [ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
signature.asc
Description: OpenPGP digital signature
