[libvirt] Redesigning Libvirt: Adopting use of a safe language

[Daniel P. Berrange]

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 :|