Golang monkey patching

Question

I understand that if go code is structured such that it's programmed to interfaces, it's trivial to mock; however, I'm working with a code base that I cannot change (that is not mine) and this is not the case.

This code base is heavily interconnected and nothing is programmed to an interface, only structs, so no dependency injection.

The structs, themselves, only contain other structs, so I can't mock out that way either. I don't believe that I can do anything about methods, and the few functions that exist are not variables, so there's no way that I know of to swap them out. Inheritance isn't a thing in golang, so that's a no go as well.

In scripting languages like python, we can modify the objects at runtime, aka monkey patch. Is there something comparable that I can do in golang? Trying to figure out some way to test/benchmark without touching the underlying code.

score 15 · Accepted Answer · edited May 23 '17 at 12:02

15

When I have run into this situation my approach is to use my own interface as a wrapper which allows mocking in tests. For example.

type MyInterface interface {
    DoSomething(i int) error
    DoSomethingElse() ([]int, error)
}

type Concrete struct {
    client *somepackage.Client
}

func (c *Concrete) DoSomething(i int) error {
    return c.client.DoSomething(i)
}

func (c *Concrete) DoSomethingElse() ([]int, error) {
    return c.client.DoSomethingElse()
}

Now you can mock the Concrete in the same way you would mock somepackage.Client if it too were an interface.

As pointed out in the comments below by @elithrar, you can embed the type you want to mock so you are only forced to add methods which need mocking. For example:

type Concrete struct {
    *somepackage.Client
}

When done like that, additional methods like DoSomethingNotNeedingMocking could be called directly on Concrete without having to add it to the interface / mock it out.

edited May 23 '17 at 12:02

Community

1
1

answered May 06 '16 at 19:02

sberry

128,281
18
138
165

I want to make sure that I'm understanding this correctly. You're suggesting to define a struct wrapping whatever struct that I'm dealing with. Define methods on said newly introduced struct that call the methods of the wrapped struct. Define an interface over the wrapper struct, then selectively mock out whatever subset of the underlying logic that needs to be mocked out? If my interpretation is correct, this seems like I'd just be rewriting all of the code given that it's so intertwined. Perhaps this is to be expected--guess there may not be an alternative. – Steve P. May 06 '16 at 19:32
That, unfortunate as it may be, is exactly what I am suggesting. – sberry May 06 '16 at 19:40
4

You don't need to call/mock the methods you don't need to override. You embed the original type inside your type, which promotes the methods, and then only override the methods you want to: https://play.golang.org/p/oHW1JX8iFb – elithrar May 06 '16 at 21:51
@elithrar Not a bad idea. Typically I end up making my interface functions more complex than straight pass-thrus (as I did in this example) but you are right indeed about an embedded type. – sberry May 06 '16 at 21:55
the problem with @elithrar idea is that the overridden method, when used inside another method isn't called, but the original one is. – Cirelli94 May 04 '20 at 10:03

score 3 · Answer 2 · answered Aug 02 '16 at 23:37

3

There is an available monkey patching library for Go. It only works for Intel/AMD systems (targeting OSX and Ubuntu in particular).

answered Aug 02 '16 at 23:37

Allen Luce

7,859
3
40
53

score 2 · Answer 3 · answered Jun 18 '18 at 20:44

Depending on the situation, you can apply the "Dependency Inversion Principle" and leverage Go's implicit interfaces.

To do this, you define an interface of your requirements in the package with the usage (as opposed to defining what you provide in the package that implements it; like you might in Java).

Then you can test your code in isolation from the dependency.

Typical object with a struct dependency:

// Object that relies on a struct
type ObjectUnderTestBefore struct {
    db *sql.DB
}

func (o *ObjectUnderTestBefore) Delete() error {
    o.db.Exec("DELETE FROM sometable")
}

Apply Dependency Inversion Principle (with implicit interface)

// subset of sql.DB which defines our "requirements"
type dbExec interface {
    Exec(query string, args ...interface{}) (sql.Result, error)
}

// Same object with it's requirement defined as an local interface
type ObjectUnderTestWithDIP struct {
    // *sql.DB will implicitly implement this interface
    db dbExec
}

func (o *ObjectUnderTestWithDIP) Delete() error {
    o.db.Exec("DELETE FROM sometable")
}

score 0 · Answer 4 · answered Apr 27 '23 at 12:49

0

https://github.com/agiledragon/gomonkey gomonkey is better than bouk/monkey, support Apple arm64 arch

answered Apr 27 '23 at 12:49

WeizhongTu

6,124
4
37
51

Golang monkey patching

4 Answers4

Linked