Mocking single methods in Go - testing

Question

In Go, how can I mock an interface without having to implement every method? Let's say I have a Car interface and a Corolla struct that implements that interface:
type Car interface {
changeTire()
startEngine()
....
refuel()
}
type Corolla struct {
...
}
func (c Corolla) changeTire() {...}
func (c Corolla) startEngine() {...}
func (c Corolla) refuel() {...}
Let's say I also have a Garage struct that depends on Car:
type Garage struct {
MyCar Car
}
func (g Garage) PrepareCarToDrive() {
g.MyCar.changeTire()
g.MyCar.refuel()
g.MyCar.startEngine()
}
And I want to test Garage, so I create a MockCar that implements Car
type MockCar struct {
...
}
func (c MockCar) changeTire() {...}
func (c MockCar) startEngine() {...}
func (c MockCar) refuel() {...}
Now I have tests that test PrepareCarToDrive and I use the MockCar:
func TestGarage_PrepareCarToDrive_DoesSomething(t *testing.T) {
mockCar := MockCar{}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do X
...
}
func TestGarage_PrepareCarToDrive_DoesSomethingElse(t *testing.T) {
mockCar := MockCar{}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do Y
...
}
My question is, how can I have mockCar do different things each test? I know that I can create a different mock implementation of Car for each test. But this will get out of hand really quickly as I add more methods to Car.
I'm coming from a Java background so I'm looking for something like Mockito that will let me mock just the methods I need for each test.
What is the best way to do this in Go? Or am I missing something more fundamental?

Answer 1

If you embed the interface type itself in your mock struct, you can then only implement the methods you need. For example:
type MockCar struct {
Car
...
}
func (c MockCar) changeTire() {...}
Even though your struct only implements changeTire explicitly, it still satisfies the interface because the Car field provides the rest. This works as long as you don't try to call any of the unimplemented methods (which will cause a panic because Car is nil)

Answer 2

The easiest method is to use some base implementation as an embed for your test structure, and only override the method you're testing. Example using your types:
type MockCar struct {
Corolla // embedded, so the method implementations of Corolla get promoted
}
// overrides the Corolla implementation
func (c MockCar) changeTire() {
// test stuff
}
// refuel() and startEngine(), since they are not overridden, use Corolla's implementation
https://play.golang.org/p/q3_L1jf4hk
An alternative, if you need a different implementation per test, is to use a mock with function fields:
type MockCar struct {
changeTireFunc func()
startEngineFunc func()
....
refuelFunc func()
}
func (c MockCar) changeTire() {
if c.changeTireFunc != nil {
c.changeTireFunc()
}
}
func (c MockCar) startEngine() {
if c.startEngineFunc != nil {
c.startEngineFunc()
}
}
func (c MockCar) refuel() {
if c.refuelFunc != nil {
c.refuelFunc()
}
}
// test code
func TestGarage_PrepareCarToDrive_DoesSomething(t *testing.T) {
// let's say we require refuel(), but the default implementation is fine
// changeTire(), however, requires a mocked testing implementation
// and we don't need startEngine() at all
mockCar := MockCar{
changeTireFunc: func() {
// test functionality
},
refuelFunc: Corolla.refuel,
}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do X
...
}
https://play.golang.org/p/lf7ny-lUCS
This style is a bit less useful when you're trying to use another type's methods as the default implementation, but can be very useful if you have some stand-alone functions that can be used as your default or test implementation, or if a trivial return is acceptable for functions you haven't specifically mocked (like the behavior of the mocked startEngine() in the example above, which does nothing at all when called because the startEngineFunc field is nil).
You can also, if you wish, bake the default implementation (like a call to (Corolla{}).startEngine()) into the mock method if the relevant function field is nil. This allows you the best of both worlds, with a default non-trivial implementation and the ability to hotswap out implementations at will on the mock just by changing the relevant function field.