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/b741bb44-75fc-434d-b4bf-8f086b48c956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
