Thanks, It seems that opinions differ about the incremental improvement of putting this in. After thinking about it I also think it is probably better to keep it simple in the core language, and no reason for it not to be a library for functional programming aficionados, and syntax nitpicks :). If you do not worry how your code looks indeed the same can be accomplished using:
|> Kernel.==(expected_result) |> assert with match? we have to create a function to swap the arguments, and you can do the same. I published it as assert_functional (https://hex.pm/packages/assert_functional), and I used it in the tests of another package (if you are interested how to apply it) if_ok (https://hex.pm/packages/if_ok). Thanks for your feedback. Always interesting to build up a body of knowledge about how the community thinks about a particular subject. @eric: Why do you think they are both imperative, and how would you make them more declarative? Very interested! Cheers, Jaap On Friday, September 30, 2016 at 1:51:14 AM UTC+8, Ben Wilson wrote: > > I also disagree that it's more declarative. > > In the standard ExUnit case, you have some setup code, and then the > assertion is a clear and easily distinct line. It's clear what is the > pattern, and what its being matched against. > > both = and the existing match? function take the pattern on the LHS so > assert_match in particular is a bit odd because it's now on the RHS. > > On Thursday, September 29, 2016 at 12:39:47 PM UTC-4, Eric Entin wrote: >> >> I disagree that the latter is more declarative than the former. They are >> just two different ways of writing the same thing. In fact, they're both >> fairly imperative. :) >> >> Pipes are awesome, but IMO they are a tool for convenience, and not the >> only way that clean, idiomatic Elixir code can be structured. I think the >> number of asserts that you will eventually have to implement here is >> another good argument against this, as people reading your code will now >> have to know both the standard Elixir operators as well as the names of the >> special matchers you create. >> >> I can definitely see your reasons for wanting this, so I think a library >> would be welcome, but I'm not in support of this being added to core at >> this time. >> >> On Thursday, September 29, 2016 at 6:23:45 AM UTC-4, Jaap Frolich wrote: >>> >>> Probably you have run into this: if you have slightly more complex tests >>> than testing the output of a single function, you need assignment and then >>> assert that assignment with an operator. Consider this controller test in >>> phoenix: >>> >>> conn = >>> build_conn() >>> |> post("/upload_content_cover", params) >>> >>> >>> assert %{"success" => true} = json_response(conn, 200) >>> >>> >>> with an `assert_match` function this translates to the following: >>> >>> build_conn() >>> |> post("/upload_content_cover", params) >>> |> json_response(conn, 200) >>> |> assert_match(%{"success" => true}) >>> >>> >>> I prefer the latter, because it is more declarative. >>> >>> My issue with using operators in assertions, is that while improving >>> readability in some cases, they are not very functional constructs, and >>> thus do not compose well. Having a functional equivalent for the >>> assertions, makes sense in a functional language in my opinion. >>> >>> I can also see why this should be a library, keeping the assertion >>> library less complex. Just would like to share my thinking. I'm also >>> interested in feedback, and how I might be wrong :). >>> >>> See the following pull request for an implementation: >>> https://github.com/elixir-lang/elixir/pull/5259. >>> >> -- 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/2525918f-5001-41bc-a23d-6aeb228e1904%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
