Allow errors and warnings in test env #1561
Conversation
A small 10ms sleep fixes issues with `on_disconnect` in `DeviceSocket` to close cleanly
test/support/channel_case.ex
Outdated
| @@ -35,6 +35,9 @@ defmodule NervesHubWeb.ChannelCase do | |||
| pid = Ecto.Adapters.SQL.Sandbox.start_owner!(NervesHub.Repo, shared: not tags[:async]) | |||
| on_exit(fn -> Ecto.Adapters.SQL.Sandbox.stop_owner(pid) end) | |||
|
|
|||
| # This extra sleep fixes Ecto ownership errors in the logs | |||
| on_exit(fn -> Process.sleep(10) end) | |||
There was a problem hiding this comment.
I have a hard time adding any sleeps to test. This is essentially 10 * channel test count. It's seems you're adding to avoid some annoying logs but I think we could change the approach to solve it as well
Instead of capturing logs for a few tests, we enable logging, but then at capture_log: true to the start function of test_helper.exs for all tests. I believe the ExUnit behavior is to print the logs it captured when test fails which would give us the useful output only when needed.
If that's not the case then I guess I'll need to help figure out how to get rid of the annoyance and not have sleeps 😉
There was a problem hiding this comment.
I can totally understand the feeling that adding sleeps to tests is a code smell.
I think it might be best to show these errors in a Zoom and see if there are other options available.
|
I attached a commit with my recommendation to show what I was describing. I think this is the net-same behavior you were looking for without crazy log configuration and/or sleeps. For example, here is a test failure with some logs injected in the code and they show up with the test results
|
Removes all the custom work of controlling logs and instead relies on ExUnit tooling to capture and handle logs when they are useful. This will keep the output clean unless a failure occurs and then it will output the captured logs with the test
jjcarstens
force-pushed
the
allow-errors-and-warnings-in-test-env
branch
from
2dc5ba7 to
aae2a37
Compare
There are times when it's useful to see the log output when running tests, but we have disabled the logs.
I've brought back the default log settings while capturing logs from specific tests where errors and warnings are emitted within the functions being called.