Skip to content

Introduce 'stub_all' option #78

Merged
merged 3 commits into from Oct 24, 2012

2 participants

@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
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)
@eproxus
Owner

The case statement can be rewritten as follows:

case Exports of
    undefined ->
        [];
    Exports when Passthrough ->
        [passthrough_stub(FuncArity) || FuncArity <- Exports];
    Exports when StubAll ->
        [void_stub(FuncArity) || FuncArity <- Exports];
    _ ->
        []
end

I think it is a little more cleaner, what do you think?

@eproxus
Owner

val(meck_stub) only? (without meck:)

@horkhe
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
Owner

There's probably a bug here when someone uses {stub_all, undefined}, should probably use proplists:is_defined/2 for this. Please also add a test case for this particular scenario.

@eproxus
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
horkhe commented Oct 23, 2012

Fixed this case too.

@horkhe
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
Owner
eproxus commented Oct 24, 2012

Nice work!

@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
Something went wrong with that request. Please try again.