Describing changeset validations

A particular test's expected results can be described with changeset (lines 4-5):

    category(                           :success,
      ok: [
        params(      age: 1, date:   "2001-01-01"),
        changeset(
          changes: %{age: 1, date: ~D[2001-01-01]}
        )]
    ) |> 

That constructs (in effect) this assertion pipeline:

Schema.changeset(%Schema{}, Tester.params(:ok))
|> assert_valid
|> assert_changes(age: 1,
                  date: ~D[2001-01-01])

Notice that the assert_valid wasn't made explicit. It's implied by the name of the category: :success(line 1). (Similarly, the:validation_failurecategory implies assert_invalid.)

The changeset function supports all of the changeset assertions from ecto_flow_assertions. Just leave off the assert_ prefix and the changeset argument. For example:

    category(                 :validation_failure,
      bad_date: [
        params(    age: 1, date: "2001-1-1"),
        changeset(
          changes: %{age: 1},
          no_changes: [:date],
          errors: [date: ~r/invalid/]
        )]
      )

Because this code reuses ecto_flow_assertionsand ecto_flow_assertions reuses ExUnit's reporting machinery, you get good error messages:

colorization! and more!

That's important because test generation frameworks are notorious for creating errors that are hard to understand.