I think that unit tests such as they exist in Elixir, which is an imperative functional language, IMO, are inherently imperative. Property tests would be a nice example of a more declarative testing style.
On Friday, September 30, 2016 at 1:01:30 AM UTC-4, Jaap Frolich wrote: > > 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/bd913a69-03fc-4f35-9dbf-36249fbcc36e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
