I imagine the behaviour of assert and refute aren't going to change, as
that'd be a breaking change. assert foo() == false is pretty clear as a
work around though.
On Friday, May 27, 2016 at 4:23:50 PM UTC-4, Sergii Boiko wrote:
>
> Maybe a little bit offtopic, but my main issue with ExUnit is that assert
> and refute match on truthiness and falsiness instead of strict true/false
> match.
> First run into it when my test suddenly passed on empty function, because
> it expected false, but refute accepts nil as well.
>
> The same issue was with Rspec 2, but they fixed it in RSpec 3. Maybe it's
> possible to address it with some special option?
>
> On Friday, May 27, 2016 at 6:18:30 PM UTC+2, José Valim wrote:
>>
>> Hi everyone,
>>
>> There are two recurrent complaints about ExUnit when writing tests:
>>
>> 1. It does not support grouping
>> 2. It does not allow developers to name nor compose setup
>>
>> The only way in ExUnit to declare some code as part of a setup is by
>> declaring a setup block and calling the function inside the block, like
>> this:
>>
>> setup context do
>>
>> {:ok, login_as(context)}
>>
>> end
>>
>>
>> I would like to propose improvements for those two issues. I will first
>> write a proposal including code samples and then we can discuss naming and
>> implementation details.
>>
>> ## Groups and named setups
>>
>> The idea is to introduce the group/2 macro and allow atoms to be given to
>> setup:
>>
>> defmodule StringTest do
>>
>> use ExUnit.Case, async: true
>>
>> group "String.capitalize/2" do
>>
>> setup :set_test_string
>>
>> test "capitalizes the first letter", context do
>>
>> assert "T" <> _ = context.test_string
>>
>> end
>>
>> end
>>
>>
>> group "String.bar/2" do
>>
>> setup context do
>>
>> # Regular setups are not going anywhere and will still work
>>
>> # You may return :ok | keyword | map
>>
>> end
>>
>> test "..." do ...
>>
>> end
>>
>> def set_test_string(_context) do
>>
>> %{test_string: "test_string"}
>>
>> end
>>
>> end
>>
>>
>> By using groups, we can now better organize the tests and named setups
>> allow us to easily share setup logic between groups without relying on
>> nesting.
>>
>> Internally, we can consider "setup :some_atom" to be equivalent to:
>>
>> setup context, do: context |> some_atom()
>>
>>
>> The group/2 macro will also store the group tag in the test. For example,
>> you will be able to:
>>
>> mix test --only group:"String.capitalize/2"
>>
>>
>> Setups defined in group/2 will only apply to the group. We will also
>> support @grouptag to set some tags specific to the current group. setup_all
>> cannot be called inside the group (as setup_all is always per test case).
>> We won't allow group calls to be nested (we want developers to compose at
>> the function level and not on nesting/hierarchies).
>>
>> ## Naming
>>
>> There is one big open question which is: is "group" a good name? I am
>> personally not a fan. group works fine for grouping at the unit test level
>> but it does not read nicely when you want to group based on a condition
>> (for example, group "when name is an atom").
>>
>> Here are some alternatives: context, testing, group, describe, scenario,
>> having, etc. I recommend everyone to actually try to write some
>> pseudo-groups in their tests and see what reads nicely. I would love your
>> feedback on what you think works nicely. Please include examples. :)
>>
>> One of my favorite picks is context but we already use context to mean
>> the data that goes through setup and tests.
>>
>> ## Feedback
>>
>> Please give us feedback on this proposal. Those features are mostly
>> straight-forward to implement, the most important aspects are the semantics.
>>
>> Thank you!
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/6e41ef0d-f0fd-4d93-ae75-9d6bb3374ccb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
