I think `group` is very explicit and easy to understand.
I find it much clearer than describe/context.
> group "when name is an atom"
I think this is because it is the text we would write with `context`,
but dropping the initial `when` would simply read fine IMO: group "name is
an atom"
Daniel
On Saturday, May 28, 2016 at 1:18:30 AM UTC+9, 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/1fcbcb3c-ca0a-4619-bb52-72d718d422cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
