grych

Creator of Drab

Capture compiler warnings in tests

Is it possible to capture compiler warnings in tests? I am doing a following test which should raise CompileError (and it does, test is successful):

@tag capture_log: true
test "update child should raise", fixture do
  IO.puts("\n--> the following warning is expected:")
  assert_raise CompileError, fn -> poke(fixture.socket, excluded: "Hegemon") end
end

But I am getting this warning during the tests:

warning: variable "u" does not exist and is being expanded to "u()", please use parentheses to remove the ambiguity or change the variable name
  nofile:6

This behaviour is expected. Indeed, u is not defined in the AST I am processing. Is there a way I can capture this? capture_log did not help.

9 comments

/phoenix #testing

0 2035 9

2018-10-16 17:53:51 UTC

First 9 of 9 Posts

OvermindDL1

I use code like this in my macro-heavy projects:
https://github.com/OvermindDL1/typed_elixir/blob/master/test/test_helper.exs

And it’s used like this:
https://github.com/OvermindDL1/typed_elixir/blob/master/test/typed_elixir_test.exs#L23-L29

I probably should pull my test helpers into their own library sometime. They are based on someone else’s but expanded for more features (and a bug fix).

Post #1

grych

Creator of Drab

Very interesting, thanks for sharing!

Anyway, I think I can’t use it in my case. The whole stuff is going on in runtime (I am evaluating previously saved AST). Also, assert_raise is working correctly in this case, function raises CompileError as expected. The only small issue is this warning, which I can live with, but it is annoying

Post #2

OvermindDL1

In that case I’d probably consider the warning a bug and silence it properly. ^.^

Post #3

grych

Creator of Drab

Not in this case. Let me explain more detailed.

There are few cases, when Drab.Live can’t execute the AST (because of limitations). In this case, I catch CompileError exception, and re-raise it with better explanation, so user is not completely lost

And of course, I would like to test this case.

Anyway, looks like I need to live with the warning

Post #4

OvermindDL1

Can’t you just do _u = u in the generated code?

Post #5

grych

Creator of Drab

Nope. u still does not exists

This is what I am testing:

<%= for u <- @users do %>
  <%= if u != @excluded do %><%= u %> <% end %>
<% end %>

When you update @excluded only, Drab tries to re-evaluate only that part: <%= if u != @excluded do %><%= u %> <% end %>. u does not exists there.

(BTW solution for this is there, it is to update @users and @excluded in the one poke, I just want to tell developer what to do - with better error message in CompileError).

Post #6

ryanwinchester

Interesting, I’m @deprecating some stuff right now but still testing them, and the warnings in the tests are really annoying.

I wish we could do an assert_warn (similar to assert_raise) or something that “catches” it and stops it from being printed, which I could also use to check the deprecated message.

Post #7

grych

Creator of Drab

Actually I resolved my case by completely rewriting this part of the library. This annoying warning encouraged me to do it, so I think warnings are useful. If you have one, try to find the other way to solve your issue.

Post #8