I'm a big fan of this proposal as well. I implemented ex_spec[1] to support this for my projects and I've found the "describe" and "context" names to be nice (they function as aliases).
I'm excited about composing setups (something I don't support in ex_spec), but I'm confused about how and where the composition happens. If you have a setup at the top-level and then more (named or traditional) setups in the groups, are they composed? Are the setups in the group only specific to that group? Thanks, looking forward to this! - Drew [1] - https://github.com/drewolson/ex_spec On Fri, May 27, 2016 at 11:39 AM, 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]> 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 >> <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]. > 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. > -- 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/CAN3B1jejf4_ZjWxOU%2BOSvQ4Dr51YuP79s137Z-58DvUxcOQ6jA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
