Flow Assertions v0.2.0 FlowAssertions.Define.BodyParts View Source

Functions helpful in the construction of a new assertion.

Mostly, they give you more control over what's shown in a failing test by letting you set ExUnit.AssertionError values like :left and :right.

All such functions take a string first argument. That's shorthand for setting the :message field.

Link to this section Summary

Functions

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

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

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

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

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

Link to this section Functions

Link to this function

adjust_assertion_error(f, replacements)

View Source

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

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 assertion that generated the error.

Link to this function

elaborate_assert(value, message, opts)

View Source

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.

Link to this function

elaborate_assert_equal(left, right)

View Source

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: ...
Link to this function

elaborate_flunk(message, opts)

View Source

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.

Link to this function

struct_must_have_key!(struct, key)

View Source

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.
Link to this function

struct_must_have_keys!(struct, keys)

View Source

Same as struct_must_have_key!/2 but checks multiple keys.