Hi Jose, The proposal is great, thank you.
I personally like 'group' as it is similar to common_test in Erlang/OTP. But if some other term had to be used I think 'set' or 'category' would also do. On 28 May 2016 2:18:08 AM AEST, "José Valim" <[email protected]> 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/CAGnRm4JpFn-%3DGkG_Ya-w64Qqt7OoworqUSAUgzqgWtTFU1fyrw%40mail.gmail.com. >For more options, visit https://groups.google.com/d/optout. -- Best wishes, Dmitry Belyaev -- 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/942DF6BB-6683-4972-AAA8-33897D0D28EC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
