test_group is not elegant. But it is scalable if you consistently prefix all these keywords with test_ e.g. test_setup This creates a separate namespace for test-related words. Could be the way to go if you want to have a lot of them.
Another word that comes to mind is "collection" Gleb On Sat, May 28, 2016 at 2: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/CAGnRm4J-DbM9Nt6M743mGxBkKhE5i9Y3QajtBFaGoogCXNPa0Q%40mail.gmail.com. > > 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/CACZNi5-2sZi66oTyY5uM1HovRBFEEGC0ucW%2BKJinmXfGaY-sUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
