[erlang-questions] Fault injection for testing?

[Michal Ptaszek]

Hi!

You might want to use e.g. meck
https://github.com/esl/meck

to simulate some uncommon scenarios. 
Nonetheless, as mocking 'file' module might be
a little bit tricky, I would recommend creating an
interface module, which should be transparent
during the normal life cycle and easily mocked
when performing the tests, e.g.:

-module(file2).
-compile(export_all).
write_file(Filename, Data) ->
   file:write_file(Filename, Data).

Then, you can easily run:
meck:new(file2).
meck:expect(file2, write_file, {error, my_error_code}).

Best regards,
Michal Ptaszek


On Dec 20, 2010, at 5:32 AM, Attila Rajmund Nohl wrote:

> Hello!
> 
> Testing error handling is complicated, because it might be hard to
> cause the error situation in the first place, which in my case it's a
> file writing error:
> 
>    case file:write_file(FileName, <<Index:8/integer>>) of
> 	ok -> ok;
> 	Error ->
> 	    io:format(standard_error, "~p ~p Error: '~p' ~n", [?MODULE, ?LINE, Error]),
> 	    exit(open_lastwritten_file)
>    end.
> 
> I could modify my code to fail is some debug flag is turned on, but it
> has a (minor) performance impact. My other idea is to make sure that
> the write_file fails by injecting the fault into the OTP library, i.e.
> before the testcase runs in the automatic tests, load a faulty 'file'
> module where the write_file function fails (I happen to know the
> filename, so it won't fail for other uses), execute the testcase, then
> remove the faulty file module.
> 
> Do you have any other ideas on how to test these kind of error
> handling code? Testing the function separately, outside the whole
> application doesn't do it, because it wouldn't detect possible
> deadlocks (the original version of this code actually had a deadlock).
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>