Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promote meck_history:result to meck API...? #249

Open
rogerl-happening opened this issue Aug 13, 2024 · 4 comments
Open

Promote meck_history:result to meck API...? #249

rogerl-happening opened this issue Aug 13, 2024 · 4 comments

Comments

@rogerl-happening
Copy link

I was looking for a way to grab the result of a mocked call. Currently, I'm just peeking into meck:history().

So I went to implement something like meck:capture(..., result), when I noticed that meck_history:result() exists. It was added in #163.

But it was demoted from the top-level meck API. I think this was a mistake -- it ought to be at the same level of abstraction as meck:capture.

Can we put it back? Or can we make meck:capture take ArgNum | result...?

@eproxus
Copy link
Owner

eproxus commented Aug 14, 2024

Yeah, good point. There is a risk of polluting the API with a lot of very specific functions that could perhaps be generalized a bit.

What do you think about adding a new function that somehow grabs a function call from the history using some nice API (like capture/5,6 or similar?) and then returns a tuple with {Args, Result} or something?

@rogerl-happening
Copy link
Author

I'm not quite sure what you're suggesting here.

Are you suggesting adding (for the sake of argument) meck:history(Occur, Mod, Func, OptArgsSpec)? That would call into (e.g.) meck_history:lookup. There's some common code in meck_history:capture() and meck_history:result() that does that, so they could both use lookup() to reduce duplication.

Or something else?

I quite like the meck:capture(..., result) thing (see #250), precisely because it adds a tiny amount of API surface.

@eproxus
Copy link
Owner

eproxus commented Aug 14, 2024

I guess I'm arguing for soft-deprecating capture in favor of something more generic.

I see it as meck:history/1+2 being the firehose, and capture/5+6 is a very specific subset of that ("give me one call and that particular argument value from it). It feels like there's something missing in-between, like "give me the arguments and return value from 'that particular call'", if that makes sense.

meck:history().
% [{<0.332.0>,{foo,bar,[a,b]},ok},
% {<0.332.0>,{foo,bar,[c,d]},ok},
% {<0.332.0>,
%  {foo,baz,[wat]},
%  error,some_error,
%  [{meck_ret_spec,eval_result,4,[{file,"src/meck_ret_spec.erl"},{line,93}]},
%   {foo,baz,[wat]}]},
% {<0.345.0>,{foo,bar,[x,y]},ok}]

meck:calls(foo, bar, 2).
% [{<0.332.0>,{foo,bar,[a,b]},ok},
% {<0.332.0>,{foo,bar,[c,d]},ok},
% {<0.345.0>,{foo,bar,[x,y]},ok}]

meck:call(foo, bar, 2, last).
% {<0.345.0>,{foo,bar,[x,y]},ok}

meck:call(foo, bar, 2, first).
% {<0.345.0>,{foo,bar,[a,b]},ok}

meck:calls(foo, bar, ['_', d])
% [{<0.332.0>,{foo,bar,[c,d]},ok}]
meck:call(foo, bar, ['_', d]) % implies 'last'
% {<0.345.0>,{foo,bar,[x,y]},ok}

(Totally made up proposal, so names and arguments are not that seriously suggested, yet).

With something like that, if you want the first argument and the result you could do:

{_From, [First|_], Result} = meck:call(foo, bar, ['_', d])

To get the nth argument from the argument list, you could use lists:nth/2 for example.

@eproxus
Copy link
Owner

eproxus commented Aug 14, 2024

Another long-standing idea I have for a new version of the history API is to include timestamps too, but maybe this is scope creep at this time ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants