On Friday, 17 April 2015 10:16:07 UTC+9, jonathan...@gmail.com wrote:
Hello gophers!
I am trying to find what is idiomatic or even a good way to structure a
large "context". So this application has an interface Machine that has its
implementation switched out on different machines. Problem I have is with
testing. If I just want to stub out a single method of that interface I
have to create a stub struct with a bunch of empty functions, it becomes
unwieldy in tests. I have heard of three approaches, mock lib, split the
interface, and have a struct with function values.
Mock lib approach I would rather avoid.
Splitting the interface has the issue that now I have to pass around all
the split interfaces which are roughly equal in number to the functions in
Machine.
Hello gophers!
I am trying to find what is idiomatic or even a good way to structure a
large "context". So this application has an interface Machine that has its
implementation switched out on different machines. Problem I have is with
testing. If I just want to stub out a single method of that interface I
have to create a stub struct with a bunch of empty functions, it becomes
unwieldy in tests. I have heard of three approaches, mock lib, split the
interface, and have a struct with function values.
Mock lib approach I would rather avoid.
Splitting the interface has the issue that now I have to pass around all
the split interfaces which are roughly equal in number to the functions in
Machine.
This gives you for "free" a test struct that implements the Machine
interface, and allows you to override specific methods for testing.
type machineF struct {
Machine
}
func (machineF) F() {
... stubbed method here.
}
In your test:
var mf machineF
... use mf as a Machine
--
Paul
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
