Feature/new exception syntax

[horkhe]

This pull requests suggests a new exception expectation syntax in the spirit of just merged to the develop args-filter feature.

It introduces a new ret_spec() construction meck:raise(Class, Reason) that can be specified anywhere where a ret_spec() is expected. E.g:

meck:expect(mod, func1, 3, meck:raise(error, blah),
meck:expect(mod, func2, [{['_', 1],   meck:val(ok)},
                         {['_', '_'], meck:raise(exit, oops)}])

Moreover it is possible to specify meck:raise inside of meck:loop and meck:seq specifications. E.g.:

meck:expect(mod, func3, [{['_', 1, 2], meck:seq([ret1,
                                                 ret2,
                                                 meck:raise(error, oops)])},
                         {['_', 1, 3], meck:loop([meck:raise(error, oops),
                                                  ok])}])

Technically meck:seq and meck:loop were turned into containers that can contain any valid ret_spec() including themselves. That makes rather crazy expect specifications possible:

%% When
meck:expect(Mod, seq, 1, meck:seq([meck:val(a),
                                   meck:seq([b, c]),
                                   meck:seq([meck:raise(error, d),
                                             meck:seq([e, f, g]),
                                             h,
                                             meck:val(i)])])),
%% Then
?assertEqual(a, Mod:seq(1001)),
?assertEqual(b, Mod:seq(1001)),
?assertEqual(c, Mod:seq(1001)),
?assertException(error, d, Mod:seq(1001)),
?assertEqual(e, Mod:seq(1001)),
?assertEqual(f, Mod:seq(1001)),
?assertEqual(g, Mod:seq(1001)),
?assertEqual(h, Mod:seq(1001)),
?assertEqual(i, Mod:seq(1001)),
?assertEqual(i, Mod:seq(1001)),
?assertEqual(i, Mod:seq(1001)).

But this is just a side-effect of the implementation that will probably never be used :)

[eproxus]

This is awesome! Feature/API wise it looks really good, I'll review the code as soon as I have a bit more time.

[horkhe]

I hope that won't take long :)

[eproxus]

What's the difference between {meck_val, term()} and just term()?

[horkhe]

There is no difference. So we probably can remove it all together. But I would leave meck:val/1 function anyway. I use it in my unit tests just to clearly see where I specify ret spec as plain value.

[eproxus]

Yeah, since one always use the functions instead of the tuples, I think it's okay to leave it.

[horkhe]

ok, then :)

[horkhe]

@eproxus so, do I need to fix something here?

[eproxus]

Nope, I'll just wait for Travis CI to run the tests (or run them myself) and then I'll merge.

[horkhe]

@eproxus If you go to the Meck page at Travis CI http://travis-ci.org/#!/eproxus/meck/pull_requests you will see that build passed. There is no a note in here about that though. Probably due to some glitch in GitHub/Travis integration.

[eproxus]

Ah, I was fooled by looking for the name of the pull request rather than the last commit message. My bad. Merging now.