Mockbroker

[burke]

Semantics of the tests are identical (AFAIK), but I added an abstraction to generate trivial responses.

It's a bit duplicated from the main package, but there were only a few bad options here:

1. Expose a bunch of internals;

2. Link a bunch of testing API bits into the library;

3. Duplicate some code to generate requests.

Anyway, the major win here is that other apps can import mockbroker to test against mock brokers the same way sarama now does. This is something a bunch of different projects have been struggling with here.

@eapache @fw42 @wvanbergen

[eapache]

I take it 1) refers to the encoder and decoder interfaces and their implementations?

[eapache]

What are these?

[burke]

Compiled test files. Go creates them sometimes for reasons I'm not especially clear on.

[eapache]

I've never seen them. You can pass a flag to go test to make it leave them behind, but in normal case it does everything in /tmp so I'm not sure why these would show up.

[burke]

Not too sure. Anyway, they're sometimes created on some machines, so no reason not to gitignore them.

[burke]

Yeah, the encoders in particular. It seemed minimally horrible to do it this way, though I didn't really think very hard about it.

[eapache]

I am trying to figure out a way to split the encoder/decoder into a separate package that can be shared, and now I am wishing I didn't give up the original debate about go package subdirectories...

[eapache]

And now I'm starting to think it's best to bake it in. The only arguments against are performance and complexity. I can't imagine it realistically affects performance at all; the optimizer might even strip out the extra code when it isn't used.

Regarding complexity, I'm coming to the conclusion that the complexity caused in the API is more than offset by the complexity removed in the code. For example, all of the *_expectation.go files can be removed outright and replaced by a single MockBroker.Expect(encoder). This actually reduces overall API complexity as well, if you count both the test API and the production API.

This is something a bunch of different projects have been struggling with here.

I think this is telling - it sounds like the majority of apps using sarama have been struggling to test themselves, which suggests to me that the mock API should be part of the main sarama API for the same reason go requires the *_test.go files to be in the same directory, not in a test/ subdirectory. 'tis The Go Way.

I fully expect this to be a controversial opinion :) Am I missing any arguments against? Are there compelling arguments for another approach?