Hacker News Reader

Comment by Jabbles | Hacker News Reader

    type DummyJob struct {
        Job
    }

DummyJob now implements Job, you can override whatever methods you need.

http://golang.org/ref/spec#Method_sets

View on HN

This looks much better, although not as simple as mocking in Java with an advanced mocking tool like JMockit. It could be hard to avoid accidental integration tests with this approach.

The other half of the answer to this problem is to favor small interfaces, ideally a single method. For example, a UserStore interface could be quite large, but if it's composed of UserCreator, UserUpdater, UserFinder, and UserDestroyer subinterfaces, then you can easily arrange to only use the small, task specific, interface.

Agreed that it's all quite a bit more of a pain than using a serious mocking toolkit, though changes in testing practices and API design help substantially.

Do you mean that you're worried that calling a method on DummyJob will accidentally run some code you don't expect?

If you don't initialize the embedded interface, non-overridden methods called on the struct will panic.

http://play.golang.org/p/4aqGof1ikp

Comparing vanilla to tooled seems a bit strange. Why not compare JMockit to gomock or something?

Thanks for the tip, for some reason it never occurred to me to do this for large interfaces.

Reply on news.ycombinator.com