Re: [libvirt] Redesigning Libvirt: Adopting use of a safe language
On Thu, Nov 23, 2017 at 11:32:26AM +0100, Michal Privoznik wrote:
On 11/14/2017 06:27 PM, Daniel P. Berrange wrote:
>
This might be more tricky than one would initially think. What about
tests for instance? In our test suite we rely heavily on mocking. For
instance, virpcitest uses virpcimock which reimplements kernel behaviour
for detach/attach of PCI devices. Would it be possible to have that with
a Go program? Okay, virpcimock might not be the best example since it
mocks plain syscalls (open, close, ...). But then there are some tests
which mock more high level functions - e.g. qemuxml2argvmock.
It depends on which areas we would want to mock/test. A regular Go method
is not directly callable to from, and thus also not directly mockable with
the ELF preload / overrides tricks do. A Go method which is explicitly
exported with C calling convention, however, can be mocked in the same
manner we do now. So if we had replaced some low level infrastructure
with a Go module, we could mock at the public entry points to that Go
module which were exported to C code. We could not mock the internals
of that Go module.
For pure Go code being tested in isolation from any C code, you would
use a different approach. The general concept in Go is to define an
'interface' covering sets of APIs which you might want alternative
impls for. So if there was a bit of Go code you wanted to easily
replace in unit tests with a fake impl, you would define an interface
and fake impl that satisifies that interface. So you need to put a
little bit more thought into the code upfront to make it fakeable
in tests, but if you do that the end result is comparable.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|