Golang interfaces & mocking

Question

I'm having hard times writing unit tests in Go due to external libraries which don't expose an interface (therefore not mockable) but only pure functions. Even big ones like Google don't, so I'm wondering whether my approach is good enough. Wouldn't be good practice for libraries to provide interfaces instead of packages with only functions in order to let the user mock them?

The solution I came up with until now is wrap these packages with an interface's implementation but that seem like too much work.

I come with an example. My function could look like this

func AnyFunction() error {
    sess := session.Get("blabla")
    // logic in here...
}

where session is an imported package that returns a struct. I can't mock the package session. For this case I'm going to write a SessionInterface with an implementation, which internally calls session.

Ex:

type SessionInterface interface {
    Get(s string) Session
}

type mySessionImpl struct {}
func (me *mySessionImpl) Get(s string) Session {
  return session.Get(s)
}

For my tests now I can mock the SessionInterface and inject that one into my code

"Wouldn't be good practice for libraries to provide interfaces" - not if they're not needed. In Go, interface implementation is implicit, so interfaces are typically defined where they're consumed, not where they're implemented. — Adrian, Mar 11 '19 at 16:15
Maybe this article is interesting for you: https://www.ardanlabs.com/blog/2016/10/avoid-interface-pollution.html — apxp, Mar 11 '19 at 17:52
You can also simply use a function variable which tests can change, see [Testing os.Exit scenarios in Go with coverage information (coveralls.io/Goveralls)](https://stackoverflow.com/questions/40615641/testing-os-exit-scenarios-in-go-with-coverage-information-coveralls-io-goverall/40801733#40801733) — icza, Mar 11 '19 at 20:18
Mocking is often a bad idea for tests. Fakes and Stubs are typically much "better" in the sense of "the discriminatory power of the test increases". — Volker, Mar 12 '19 at 06:32

score 13 · Accepted Answer · answered Mar 13 '19 at 02:27

You're doing the right thing here, and this was a conscious decision on the part of the language designers.

The Go philosophy is that your code should "own" those interfaces, not the library. In languages like C# and Java, libraries define their interfaces up front, without really knowing what the consumer actually needs. (Maybe they include too many methods, or too few.) In Go, because the consumer effectively "owns" the interfaces, you're empowered to specify which methods actually need to be present in a minimal interface, and changes in your program requirements mean that you can also change the interface.

Now in this particular case it might seem strange to create an adapter in front of a function for testability, but consider the alternative: if session.Get() were a method of an interface or struct, instead of a function, it would force all library consumers to instantiate a dummy object in order to call the method. Not everyone is going to fake it out---it's easier for them to say that the consumers who want to (like you) are empowered to write adapters, and those that don't can blissfully ignore them.

dm03514 · Answer 2 · 2019-03-11T16:23:11.507

IMO this is a super common solution and strikes a good balance between maintainability and testability.

The way I think of this is that your code is programming to an interface, and there just happens to be two implementations:

"prod" version ie the library that you're testing
test version, a stub that implements the interface

With this approach, a stub can only verify up to your service and its dependencies boundary along the contract of the interface, it assures very little or nothing about your components collaboration/integration with the library that's being stubbed. In my experiences this approach works awesome and is my personal preference. I have found it to be important though to have 1 or 2 higher level tests making sure that your component can successfully initialize and interact with the "prod" version of the library.

Plug:

I've written about this exact issue https://medium.com/dm03514-tech-blog/you-are-going-to-need-it-using-interfaces-and-dependency-injection-to-future-proof-your-designs-2cf6f58db192

Golang interfaces & mocking

2 Answers2

Linked