I'm now trying to write the test driver for the interface config driver
that I'm putting into libvirt. For comparison I'm using the network
driver. My understanding so far is that it calls the functions in the
real driver to construct network objects and manipulate them, then just
doesn't call the code that makes the changes to the system config.
My driver is a bit different, in that I don't need any object management
- I just pass everything through to the netcf library, and return the
results to the caller; libvirt is just being used as an RPC conduit with
some minimal wrapping.
What I'm wondering now is exactly what the test driver should be testing
- should the test driver also call netcf and return the results, or
should it be a minimal interface driver in its own right that, for
example, comes up with no interfaces, and allows adding only one?
The former (call netcf) is problematic in that many netcf functions make
changes to the real live network config (which I don't think is a very
nice thing to have in test code, but maybe I'm being over-cautious) and
netcf doesn't have provisions for a test mode where changes made to the
config aren't committed.
In the latter case it seems that not a lot will be tested (just the
client side API, and libvirt's RPC - all parameter checking and XML
parsing will be done by netcf), although maybe that's all anyone is
looking for. I would hesitate to make the driver any more complicated
than just allowing a single interface, or do any parameter validation
that's normally done by netcf, since then much of the testing would be
of code that was only used in the test itself - not very productive.
Any advice?
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
