Personally I really don't like "describe" or "scenario"; the former forces you to group these tests by a description, the second one has a "enterprisy" feel to me :P and I don't think brings any meaningful meaning with it.
Tbh, I think group is the most fitting name for such functionality: it's very direct, you're just creating a group of tests that share something. On Friday, 27 May 2016, Josh Adams <[email protected]> wrote: > I love this proposal. I have always liked reading the `describe`-style > tests. That's my vote. > > On Fri, May 27, 2016 at 11:18 AM, José Valim < > [email protected] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','elixir-lang-core%[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 >> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JpFn-%3DGkG_Ya-w64Qqt7OoworqUSAUgzqgWtTFU1fyrw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Josh Adams > > -- > 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] > <javascript:_e(%7B%7D,'cvml','elixir-lang-core%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAA1-O0wmo0T3Bu5CpYrESkgb4z%2B2v_A%2Bu2Y3Tvr8--a8oAmC7Q%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAA1-O0wmo0T3Bu5CpYrESkgb4z%2B2v_A%2Bu2Y3Tvr8--a8oAmC7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Andrea Leopardi [email protected] -- 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/CAM9Rf%2BLLv3%3DmYo3mUe9902qS%2BvoXqTvF7CCkijy-5h7Me7kkqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
