📔
Idiosyncratic Elixir
  • Introduction
  • Testing in General
    • Flow style tests
  • Phoenix View Models
    • Single form view models
    • Testing view models
  • Declarative testing of structured (form) input
    • Preface
    • Features, described gradually
      • Describing changeset validations
      • Running tests
      • Example prototypes
      • Shorthand for built-in transformations (`cast`)
      • Shorthand for custom transformations (on_success)
Powered by GitBook
On this page

Was this helpful?

  1. Declarative testing of structured (form) input
  2. Features, described gradually

Example prototypes

Here's an example you've seen before.

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

Just as in programming, in testing it's common to want to say "This data is like that data, except..." For example, a second test might have a different :date parameter. That test cares nothing about the :age parameter, but :agemust nevertheless be supplied...

But does it have to be mentioned? It shouldn't be, because seeing it again in a new example just obscures the new example's purpose. So a new test can use params_like instead of params(line 3):

    category(                                         :validation_failure,
      bad_date: [
        params_like(:ok, except: [date: "2001-1-1"]),
        changeset(
          no_changes: [:date],
          errors: [date: ~r/invalid/]
        )]
    ) 

The changeset doesn't check the value of age, which is almost certainly OK: how likely is it that date-handling will affect what we know to be an independent schema field?

If you're unhappy about that, read on!

PreviousRunning testsNextShorthand for built-in transformations (`cast`)

Last updated 4 years ago

Was this helpful?