+1 here, more context is often useful but the diff support is crucial.

Cheers
Jon

On Mon, 15 Sep 2025, at 7:49 PM, Jason Axelson wrote:
> Big +1 from me as well. I often skip using `assert/2` because of the need to 
> re-implement the rich diffing logic that `assert/1` gives. Generally I only 
> truly want to provide additional context that will help the developer 
> understand what failed rather than wanting my own "diffing" output.
> 
> -Jason
> 
> On Mon, Sep 15, 2025 at 8:31 AM Ben Wilson <[email protected]> wrote:
>> +1 to this from me. We have a variety of asserts inside of a list that 
>> always have commented out dbg statements above them to help with failures. 
>> Passing those into assert would be great.
>> On Monday, September 15, 2025 at 1:17:49 PM UTC-4 [email protected] wrote:
>>> So, we have the assert/1 macro in ExUnit, which does a really nice job of 
>>> pointing out actual failures - a diff, etc, depending on what you give it. 
>>> We also have assert/2, a function where you can insert your own message. I 
>>> propose that we have perhaps another option: a variant of assert(assertion, 
>>> contextual_data: %{foo: "bar"}). Basically, I love that diffing we do in 
>>> assert/1, and just want to append some relevant data to the message, which 
>>> is particularly helpful if I'm running an assertion in a loop (think poor 
>>> man's property-based testing) with different data -- the line number isn't 
>>> going to allow me enough data to figure out what exactly just failed.
>>> I understand it wouldn't be trivial to do, pretty much because there's 
>>> already an assert/2 with opts and with message, and they're functions not 
>>> macros...
>>> 
>>> Sorry if I'm missing anything about proposals - this is my first one!
>>> I'm willing to maybe put some time into a PR here, if the feedback is 
>>> positive and has a bit of guidance (Elixir is my day-job, so I do have some 
>>> experience)
>>> 
>>> Thanks,
>>> Derek
>> 
>> 
>> -- 
>> 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 visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/afe45a12-091d-4980-b64d-e5974926e7cdn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/afe45a12-091d-4980-b64d-e5974926e7cdn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> 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 visit 
> https://groups.google.com/d/msgid/elixir-lang-core/CAHMz6kzuE%2BEZK5Bhb6Q0SMKO6T8S1XsAeYkeK0NjhFv4ZjBT_w%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/CAHMz6kzuE%2BEZK5Bhb6Q0SMKO6T8S1XsAeYkeK0NjhFv4ZjBT_w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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 visit 
https://groups.google.com/d/msgid/elixir-lang-core/5b0c7550-d2a0-41b8-9a07-e9b063d2dd00%40app.fastmail.com.

Reply via email to