[libvirt] [RFC PATCH 0/3] Implement mockup capabilities cache in QEMU tests

Martin Kletzander mkletzan at redhat.com
Thu Sep 3 13:34:21 UTC 2015


On Thu, Sep 03, 2015 at 09:51:11AM +0300, Pavel Fedin wrote:
> Hello!
>
>> The current xmlopt structure has two callbacks in parser
>> configuration, one for post-parsing of the whole domain XML and one
>> for device XML.  We could add new (optional) callback in this
>> structure that would be called before other post-parse callbacks, but
>> still after the xml is parsed.  This would not be utilized anywhere
>> else than in tests
>
> We don't need to add this because we already have domain post-parse callback. And this is what i
>actually disliked.
> There is a very simple way to patch this callback. Currently in our tests we call
>virQEMUDriverCreateXMLConf(), which returns a structure, containing our callbacks. Actually we could
>make a wrapper around this function which would replace domainPostParseCallback with own pointer,
>remembering the original one. Then our function would take emulator name from the parsed XML, insert
>capabilities cache, and proceed to original function.
>

It's just that we would have to replace and patch both domain callback
and domaindevice callback (domaindevice callback can be called without
domain callback) and I thought it would be nicer to have it in one
place.  But I think both works for me.

>> We should be really careful about not depending on the host in tests,
>> so any assert like this would be much appreciated.
>
> To tell the truth i'm not a big fan of test-only code in library body. But, i agree with this, and
>i see no other way round. I think we could add some global Boolean variable like bool testMode,
>which would be set to true by test suite.
> Actually, this variable could even modify capsCache behavior to ignore binary name at all, and
>return, let's say, the first entry. But we should be really careful about it because i believe we
>want to exercise the actual library code, and not some test-only code.
>

It's just an assert.  We have those for various reasons and extra
carefulness cannot hurt.  I don't think it needs differentiating
between whether the code is ran in tests or not.  That defeats the
purpose of our tests.  It'd be better to resort to mocking some simple
function if needed.

>Kind regards,
>Pavel Fedin
>Expert Engineer
>Samsung Electronics Research center Russia
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150903/0a38662b/attachment-0001.sig>


More information about the libvir-list mailing list