Error using meck:unload() that appears to get fixed by adding a ?debugFmt() on the previous line.

[youngkin]

I have a test fixture with a setup function that calls meck:new() and a teardown function that calls meck:unload(). When the teardown function is called the following error is produced:

=ERROR REPORT==== 29-Jan-2014::07:57:12 ===
Error in process <0.5203.0> with exit value: {{not_mocked,substatsDb},   
[{meck_proc,gen_server,3,[{file,"src/meck_proc.erl"},{line,443}]},  
{meck_code_gen,exec,4,[{file,"src/meck_code_gen.erl"},{line,147}]},  
{substats,loop,1,[{file,"/Users/uyounri/gitsandbox/subpub/src/su...

The error is apparently fixed by adding a ?debugFmt() statement on the previous line. Here is the code for the teardown function that appears to work:

stop(_) ->
   meck:expect(substatsDb, stop, 1, fun(dbconn) -> ok end),
   substats:stop(),
   %% Note: this a?debugFmt() call prevents a meck exit error - 
   %% Error in process <x.xxxx.x> with exit value: {{not_mocked,substatsDb}...
   ?debugFmt("", []),
   meck:unload(substatsDb).

[eproxus]

What does the ?debugFmt macro do? Can it be replaced with a timer:sleep(X) with the same result?

[youngkin]

Thanks for the quick reply!

?debugFmt() doesn't print anything, it just has to be there. timer:sleep(1) has the same effect as ?debugFmt(), the tests run just fine.

BTW, nice job with Meck. I got hung up initially on expectations, but once I figured out I could handle different inputs with a case/of things worked well. Your ErlangFactory video helped quite a bit.

Cheers, Rich

On Thu, Jan 30, 2014 at 10:04 AM, Adam Lindberg notifications@github.comwrote:

What does the ?debugFmt macro do? Can it be replaced with a timer:sleep(X)with the same result?

Reply to this email directly or view it on GitHubhttps://github.com/eproxus/meck/issues/116#issuecomment-33708473 .

[eproxus]

Awesome that you like it. :-)

What exactly happens in substats:stop()? I'm suspecting there is some race condition / process dependency here. Also, is it correct that the mock for substatsDb:stop should receive dbconn (and not _Dbconn) for example?

[youngkin]

It is correct that dbconn is correct. Just for grins I tried changing stop(_) to stop(DbConn) and passed DbConn into the expectation. That didn't help.

substats:stop() is a process and calls substatdDb:stop(). substatsDb is a wrapper for redis, an Erlang library for Redis. substatsDb:stop() calls an eredis function that cleans up Redis connection resources (at least that's my assumption). I believe eredis also uses a process for interactions with Redis. So it could be some sort of race condition.

On Fri, Jan 31, 2014 at 8:18 AM, Adam Lindberg notifications@github.comwrote:

Awesome that you like it. :-)

What exactly happens in substats:stop()? I'm suspecting there is some race condition / process dependency here. Also, is it correct that the mock for substatsDb:stop should receive dbconn (and not _Dbconn) for example?

Reply to this email directly or view it on GitHubhttps://github.com/eproxus/meck/issues/116#issuecomment-33802293 .

[eproxus]

Is substatsDb fully mocked, in the sense that no code ever reaches the redis parts? Could you try to boil it down to a more minimal test case?

[youngkin]

Hi Adam,

I believe it is, but I'll double check. I'll also get a minimal test case put together and send it along. This may take a couple of days.

Cheers, Rich

On Mon, Feb 3, 2014 at 1:54 AM, Adam Lindberg notifications@github.comwrote:

Is substatsDb fully mocked, in the sense that no code ever reaches the redis parts? Could you try to boil it down to a more minimal test case?

Reply to this email directly or view it on GitHubhttps://github.com/eproxus/meck/issues/116#issuecomment-33933302 .

[eproxus]

No worries. It's just really hard to speculate with errors like this. :-)

[eproxus]

Ok, closing for now. Please re-open in case you still have problems!

[youngkin]

Thanks, Adam.

On Mon, Mar 31, 2014 at 2:47 AM, Adam Lindberg notifications@github.comwrote:

Ok, closing for now. Please re-open in case you still have problems!

Reply to this email directly or view it on GitHubhttps://github.com/eproxus/meck/issues/116#issuecomment-39065909 .