Although a bit late to the party I want to express my immense support for this proposal. The 2 concerns you mentioned are my chief concerns and especially among people I show Elixir as well. So there is a big :+1: for this.
Not a huge fan of group/bundle - still very much like describe/context. `describe` for `describe "MyModule.fun"` and context for `context "admin"`. Glad to see ExUnit is taking this direction! Tobi On 05/28/2016 01:47 PM, Drew Olson wrote: > 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] > <mailto:[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 <http://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 <http://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 <http://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 > <http://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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAN3B1jdZbRKYRUSYzfNPvZJnyvr0HyqfrgFNHp6CeHnFDhbN8g%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAN3B1jdZbRKYRUSYzfNPvZJnyvr0HyqfrgFNHp6CeHnFDhbN8g%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/574B4759.5020301%40gmail.com. For more options, visit https://groups.google.com/d/optout.
