search

eproxus / meck

A mocking library for Erlang
http://eproxus.github.io/meck
Apache License 2.0
811 stars 231 forks source link

Getting meck_proc already started errors #217

Open SoniCoder opened 3 years ago

SoniCoder commented 3 years ago

Expected behavior

make eunit/junit COVER=1 should pass post OTP 23

Observed behavior

Getting these kinds of errors (with COVER=1) for some unknown reasons that were not coming before OTP 23

::in function meck_proc:start/2 (src/meck_proc.erl, line 93) called as start(put_functions,[passthrough]) **error:{already_started,<0.16752.0>}

This only happens with COVER=1 and succeeds when COVER=1 is not specified

Versions

OS: Debian Buster Erlang OTP 23.1.1 installed(compiled) via. kerl

eproxus commented 3 years ago

Not sure how to reproduce this. What project are you building and how?

SoniCoder commented 3 years ago

The project is private. However we have noticed that it doesn't always happen (only sometimes perhaps due to some race conditions) and only happens with cover even though we are doing teardown of that module's meck properly using meck:unload() every single time.

eproxus commented 3 years ago

Are you running tests in parallel? This error occurs when there's already a mock started for the module. Alternatively, perhaps you have a cleanup that doesn't always run properly?

SoniCoder commented 3 years ago

Not specifying any execution order and letting eunit decide everything. Have my cleanup (meck:unload()) in a try catch after block ... so as long as the cleanup function executes, I think meck:unload() should be always called. Not sure how cover sometimes interacts with all of this in a funny way.

eproxus commented 3 years ago

Sounds like a race condition somehow (asynchronous teardown of a mock at the same time as a set up). Does the error happen if you run individual test cases in isolation?

SoniCoder commented 3 years ago

have noticed this while running the individual test as well

eproxus commented 3 years ago

Getting this issue when running just one test sounds really weird, especially if you never called meck:new() before. Can you reduce the test to something minimal that I could reproduce?