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

Introduce 'stub_all' option #78

Merged
merged 3 commits into from
Oct 24, 2012
Merged

Introduce 'stub_all' option #78

merged 3 commits into from
Oct 24, 2012

Conversation

horkhe
Copy link
Contributor

@horkhe horkhe commented Oct 12, 2012

For those who use mocks in record-then-verify manner (and I am one of them :-)) it would be very convenient to create mocks that have stubs for all exported functions out-of-the-box. This feature introduces such capability. The default stubs allow everything as input arguments and return meck_stub. If in the scope of a test a more specific stub (expectation) is required, then the out-of-the-box stub (expectation) can be overridden by explicit call to meck:expect/3,4.

E.g. If there is a module m1 that exports function f/2 then:

meck:new(m1, [stub_all]),
?assertEquals(meck_stub, m1:f(blah, whatever)).

@eproxus
Copy link
Owner

eproxus commented Oct 22, 2012

Might I suggest a few changes?

  • Default return value should be ok (more Erlang-ish)
  • The option could handle {stub_all, ReturnValue} or even {stub_all, Fun} (tip: use proplists:expand/2 and family)

@horkhe
Copy link
Contributor Author

horkhe commented Oct 22, 2012

It is a neat idea to allow defining values returned by stubs. I just implemented it in a more general way. Any valid ret_spec() can be specified as a return value of the stub_all option.

@eproxus
Copy link
Owner

eproxus commented Oct 22, 2012

Alternatively we have to expand the stub_all option to {stub_all, ok} first, and then use that in combination with proplists:is_defined(stub_all, Options) to see if we can trust the return value of proplists:get_value(stub_all, Options) or not.

@horkhe
Copy link
Contributor Author

horkhe commented Oct 23, 2012

Fixed this case too.

@horkhe
Copy link
Contributor Author

horkhe commented Oct 23, 2012

I wonder, why my pull request does not have that nice green label from Travis-CI that it is ok to merge...

@eproxus
Copy link
Owner

eproxus commented Oct 24, 2012

Nice work!

eproxus added a commit that referenced this pull request Oct 24, 2012
@eproxus eproxus merged commit a6e1553 into eproxus:develop Oct 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants