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/a2bb5b47-b92d-4278-896b-37e80307de76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
