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 <d...@drewolson.org> wrote: > This is looking good, I like "bundle". Any specific reason to not support > nesting? > > Thanks! > Drew > > > On Saturday, May 28, 2016, José Valim <jose.va...@plataformatec.com.br> > 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 < >> jose.va...@plataformatec.com.br> 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 <tuvista...@gmail.com> >>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >> 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 elixir-lang-core+unsubscr...@googlegroups.com. > 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 elixir-lang-core+unsubscr...@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
