Closed Kuroneer closed 4 years ago
I would spontaneously lean towards no. 4 since this seems to be an issue with Cover printing random stuff to standard out.
Did I correctly understand it that there should be cover info for this module but it is not retrievable for some reason? Or it doesn't exist in the first place and Cover just prints this annoying message?
Fair enough
In the test case I provided, there was no cover requested (just the annoying message), but I've updated the example repository (f8106a1) to show also the cover issues.
rebar3 test
will show the annoying messagerebar3 do ct --cover, cover
will show coverage at 50%. Commenting the rpc meck new call (marked with (1)
at test/mylib_SUITE.erl:31
) and running it again will show coverage back to 100%
While running rebar3 eunit+distributed ct with meck, I see
in the stdout. I've triaged it to https://github.com/eproxus/meck/blob/3d70c4ea4b38699667a1bfea30df00f98ea11ef0/src/meck_proc.erl#L426 In this case, CT Slave nodes do not run a full cover server, but a "remote cover server", which is unable to handle this call and thus, prints the message it receives: https://github.com/erlang/otp/blob/6eb8890dd255c862a2dee539e1691011005fd5aa/lib/tools/src/cover.erl#L989-L990 Fortunately, at this point this issue is only cosmetic, although no cover data is backed.
I don't know If I should setup meck differently for distributed tests, but as I have it, it could be solved with different approaches:
so I'm reluctant to use it.
Since I don't know which way would be the best, I haven't created a PR yet, I'd gladly do that if required. I've created a sample project where this is shown
Reproduction Steps
Expected behavior
Only test output in stdout
Observed behavior
Cover warnings in stdout
Versions