eproxus/meck — pull request #74 by horkhe (2012-09-11 04:49:21+00:00)
Title: Feature/new exception syntax

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 :)