José - Thanks for the clarification, I should have read more closely.
I understand the argument against nested setups and think stopping folks from using them is a good idea. That said, I often find nested groups useful in grouping subsets of functionality within a given function (just from an organizational / naming perspective). Either way, this is a huge improvement. Thanks. On Saturday, May 28, 2016, José Valim <[email protected]> wrote: > Thank you Drew. The reason for not support nesting was mentioned in the > initial proposal. We want to push developers to compose setups by building > functions (hence the support for setup :some_code) instead of relying on > hierarchies. > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Sat, May 28, 2016 at 1:26 PM, Drew Olson <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> This is looking good, I like "bundle". Any specific reason to not support >> nesting? >> >> Thanks! >> Drew >> >> >> On Saturday, May 28, 2016, José Valim <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> Both features have been implemented here: >>> >>> 1. >>> https://github.com/elixir-lang/elixir/commit/056536add75accc02542ef84d48c8535127c4171 >>> 2. >>> https://github.com/elixir-lang/elixir/commit/58377cdeea091643c002414942dcab4e8b042b13 >>> >>> Notice we used the name "bundle" instead of "group" since it provides >>> the same idea of grouping and can be read as both noun and verb. One of the >>> benefits of the word "bundle" is that it generally does not come with the >>> expectation it can be nested. >>> >>> In any case, the naming discussion is still open for debate and feedback >>> is welcome. >>> >>> >>> >>> *José Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Director of R&D >>> >>> On Sat, May 28, 2016 at 8:53 AM, José Valim < >>> [email protected]> wrote: >>> >>>> Thanks everyone for the feedback so far. >>>> >>>> It is very likely we won't go with the term "group". It is an >>>> overloaded term and given the direction we are taking with GenStage and >>>> GenBroker, I wouldn't be surprised if we end-up adding Kernel.group/2 or >>>> something similar in the future. Group or group by is an essential in many >>>> collection handling operations and there is nothing specific to test in >>>> "group". >>>> >>>> Here are other suggestions that came up: "grouping", "bundle", >>>> "test_group". >>>> >>>> >>>> >>>> *José Valim* >>>> www.plataformatec.com.br >>>> Skype: jv.ptec >>>> Founder and Director of R&D >>>> >>>> On Sat, May 28, 2016 at 8:39 AM, Daniel Perez <[email protected]> >>>> wrote: >>>> >>>>> 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/CAGnRm4L6iRmHzfjQmXn0vTC0E%2B3gW1%3Drqj_eett1YvCfwOrXAg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L6iRmHzfjQmXn0vTC0E%2B3gW1%3Drqj_eett1YvCfwOrXAg%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] >> <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/CAN3B1jdTD3nO6So_YD-aVkN6Hfc7dCBajnpfMbjoj0RSJtpMLQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAN3B1jdTD3nO6So_YD-aVkN6Hfc7dCBajnpfMbjoj0RSJtpMLQ%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] > <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/CAGnRm4%2BOCkrn%2Bq588%2Bc8DD%2BuHbAbwFO79BZhoCXczYrXZ9UUrA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BOCkrn%2Bq588%2Bc8DD%2BuHbAbwFO79BZhoCXczYrXZ9UUrA%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/CAN3B1jdZbRKYRUSYzfNPvZJnyvr0HyqfrgFNHp6CeHnFDhbN8g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
