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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
