meck:validate/1 always returns true

[svetlin-mladenov]

To reproduce:

meck:new(dog).
meck:expect(dog, bark, fun() -> "Woof!" end).
meck:validate(dog).

validate returns true but the expected value is false because the bark function hasn't been called yet.

[horkhe]

According to the validate edoc "The function returns true if the mocked module(s) has been used according to its expectations. It returns false if a call has failed in some way. Reasons for failure are wrong number of arguments or non-existing function (undef), wrong arguments (function clause) or unexpected exceptions." It does not check that everything that you set expectations for is called, it just make sure that nothing crashed during your test so to speak.

I would recommend you to use meck in record-verify manner, that is to treat expectations as stubs that are defined in you test Given section and verify that post-conditions are met with num_calls/3 function in the test Then section.

[svetlin-mladenov]

OK. I get it. But I think the names and the documentation is confusing. When I use meck:expect I expect something and I also expect meck:validate to validate that the mocked module(s) has been used according to my expectations. But obviously the expectations of meck and my expectations are different, then why is meck:expect called "expect" why not "stub" or "when"?

Still, thank you for the quick response and clarifications.

[horkhe]

I started contributing to this project just recently, and I do not know the original author's intention. It is hard to guess since on the one hand the name of the main function is expect that tells that it is an expectation framework, but on the other hand expect does not allow expecting a particular number of invocations and verification functions (called and num_calls) are provided that are typical for record-verify frameworks.

My personal desire is to move Meck API and feature set more towards the record-verify model of use (like Mockito in Java). And all I do is driven by this purpose. But that is just my opinion and Adam (@eproxus) - the project author - might not side with me. But if majority of Meck user base supports this motion then it will probably happen, and expect will be substituted with stub or at least stub synonym will be provided.

I am going to write a Wiki page that explains how to use Meck in record-verify style but for that I need a couple of more features to make it at least in to the develop branch.

[svetlin-mladenov]

Well, breaking the API just to fix a couple of bad names sounds like too much to me. Mockito is a pretty good framework but currently using meck one can do almost everything that can be done using Mockito. What I want to see is more erlang specific features not just a clone of Mochito. I would like to see more features that allow to mock interaction between processes more easily. For example:

Pid = meck:new_proc(),
... do something with Pid
meck:received(Pid, Message_pattern) %true if Pid received a message that matches the Message_pattern

[eproxus]

The name expect was just picked in the beginning as something of a "expect this result when the function is called", not "expect this function to be called". I agree that the naming is not the best, and am open for suggestions on better names that can be added as alias functions provided they provide a bigger improvement.

I've often though about added helpers for processes, but the conclusion has always been that Meck wouldn't be able to provide some significant improvement over Erlang itself in this regard. Consider:

Pid = self(),
... do something with Pid
receive Message_pattern -> true; _ -> false end %true if Pid received a message that matches the Message_pattern

The gain is not so big. If some more structure is needed one can easily add a small helper function in ones tests. Generalizing this one often just ends up with abstractions over Erlang's own pattern (!, recieve etc.).

That said, I'm happy to get any suggestions on how this could be done, of course.

[bobergj]

While helpers for this simple case would be an unnecessary abstraction, some helpers could be useful, eg when
waiting for a sequence of messages.
I strongly believe that it is more useful to express that kind of logic as a state machine though. Something like quickchecks state machines/trace verification mechanism. Will do some more thinking :)