Open sixstone-qq opened 5 years ago
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.
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.
@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?
There are cases where two or more different feliceProducer.Send
are called, so that's not a good option.
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
andkey
. I am using a mock of the producerSend
function, which looks like that: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 :)