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