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