Ease producer testing

[sixstone-qq]

As a user of felice, which is great, by the way, I'd like to test what I'm actually sending, that is, topic, body and key. I am using a mock of the producer Send function, which looks like that:

p.SendFunc = func(_ context.Context, topic string, v interface{}, opts ...fproducer.Option) (*fproducer.Message, error) {
// Test the body
require.Equal(t, &Object{}, v)
// Test topic
require.Equal(t, "my-topic", topic)
// Test the key
mess := producer.NewMessage(topic, "")

opts[0](mess)
k, err := mess.Key.Encode()
require.NoError(t, err)

require.Equal(t, "awesome-key", string(k))

The last part is almost impossible to write it without knowing all insights of library. Is there any better way to test it given the previous constraint? If so, I'd love to have it documented in godoc, if not, a helper would be great :)

[tealeg]

Thanks for raising that @sixstone-qq - I hadn't really considered that you wouldn't just trust it to do the right thing as downstream user. We provide quite a bit of test coverage within the project.

[sixstone-qq]

What we are testing here is the code between the service and felice so we are sure what felice receives is correct, so our function is likely to be like that:

func (s *Sender) Send(ctx context.Context, o *Object) error {
    // some code to send what's needed from o Object
    // sender_code
    feliceProducer.Send(ctx, dynamic_topic, manipulated_object, dynamic_key)
}

So we want to test is sender code.

[tealeg]

@sixstone-qq so you want to test that (in the above example) Sender.Send is passing the right parameters to felice's Producer.Send post manipulation? Testing this shouldn't require you to know anything about Felice's internals. I would move the code that does the manipulation of the Object to its own function (called from within Sender.Send) and test it in isolation. Or am I still missing the point?

[sixstone-qq]

There are cases where two or more different feliceProducer.Send are called, so that's not a good option.