What if meck:expect could merge instead of replacing?

[edgurgel]

So instead of writing this:

meck:expect(Mod, f, [{[1001], meck:raise(error, a)},
                     {[1002], meck:raise(throw, b)},
                     {[1003], meck:raise(exit, c)},
                     {[1004], meck:val(d)}]),

We could write this:

meck:expect(Mod, f, [1001], meck:raise(error, a))
meck:expect(Mod, f, [1002], meck:raise(throw, b))
meck:expect(Mod, f, [1003], meck:raise(exit, c))
meck:expect(Mod, f, [1004], meck:val(d)})

(This could be an option like: meck:new(Mod, [:merge]))

Thoughts?

I could try to send a PR with this feature if someone could provide some guidance :)

[eproxus]

I like the idea in general. I think adding it to the code would make it a lot more complex (I might be wrong, and if you work on a PR I'd like to see the results).

I've also often thought about an API for Meck 2.0. This could go into such a draft.

[eproxus]

The relevant places to start looking are:

https://github.com/eproxus/meck/blob/master/src/meck.erl#L225
https://github.com/eproxus/meck/blob/master/src/meck_expect.erl#L47
https://github.com/eproxus/meck/blob/master/src/meck_proc.erl#L226

Note that an Expect specification in Meck is something that is completely overwritten each time it is set (hence the way it works today). So, to change this you'd need some kind of state in the mock process with the Expect state so far, and what is to be added (in case the option is set) or overwritten.

[edgurgel]

Cool! Thanks for the tips! I will open a PR as soon as I have something working 👍