4 ms·
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 t
by cryptos 12y ago
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.
- rancor 12y agoThe 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.
- Jabbles 12y agoDo 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 http://play.golang.org/p/4aqGof1ikp
- MetaCosm 12y agoComparing vanilla to tooled seems a bit strange. Why not compare JMockit to gomock or something?