Run a function, perhaps generating an assertion error. If so, use the keyword arguments to replace or update values in the error.

Replacement:

adjust_assertion_error(fn ->
  MiscA.assert_good_enough(Map.get(kvs, key), expected)
end, 
  message: "Field `#{inspect key}` has the wrong value",
  expr: AssertionError.no_value)

Setting the expr field to AssertionError.no_value has the handy effect of making the reporting machinery report the code of the assertion the user called, rather than the nested assertion that generated the error.

Update:

adjust_assertion_error(fn ->
  MiscA.assert_good_enough(Map.get(kvs, key), expected)
end, 
  expr: fn expr -> [expr, "..."] end) # indicate something missing.

See also adjust_assertion_message/2

Run a function, perhaps generating an assertion error. If so, call the second function, passing the current assertion message as its argument. The result is installed as the new assertion message.

 adjust_assertion_message(
   fn -> flunk "message" end,
   fn message -> "#{message} and #{message}" end)

See also adjust_assertion_error/2"

Like ExUnit.Assertions.assert/2 but the third argument is used to set AssertionError keys.

  elaborate_assert(
    left =~ right,
    "Regular expression didn't match",
    left: left, right: right)

Warning: as far as I know, the structure of ExUnit.AssertionError is not guaranteed to be stable.

See also elaborate_assert_equal/4.

This replicates the diagnostic output from assert a == b, except for the code snippet that's reported.

The user will see a failing test containing:

Assertion with == failed
code:  assert_same_map(new, old, ignoring: [:stable])
left:  ...
right: ...

... instead of the assertion that actually failed, something like this:

Assertion with == failed
code:  assert Map.drop(new, fields_to_ignore) == Map.drop(old, fields_to_ignore)
left:  ...
right: ...

Like ExUnit.Assertions.flunk/1 but the second argument is used to set AssertionError keys.

elaborate_flunk("the value is wrong", left: value_to_check)

Warning: as far as I know, the structure of ExUnit.AssertionError is not guaranteed to be stable.

See also elaborate_assert/3.

elaborate_assert/3, except the value is expected to be falsy.

Flunk test if it checks structure fields that don't exist.

It doesn't make sense to write an assertion that checks a field that a structure can't contain. If a user tries, this function will object with a message like:

Test error: there is no key `:b` in a `MyApp.Struct`

Notes:

• It's safe to call on non-struct values.
• It returns its first argument.

Same as struct_must_have_key!/2 but checks multiple keys.