Assertions and helpers for a better JSON testing experience in Elixir.

Using ESpec? Check out test_that_json_espec.

• is_json_equal
• has_json_keys
• has_only_json_keys
• has_json_values
• has_only_json_values
• has_json_properties
• has_only_json_properties
• has_json_path
• has_json_type
• has_json_size

• parse_json
• parse_json!
• to_json
• to_json!
• prettify_json
• prettify_json!
• to_prettified_json
• to_prettified_json!
• load_json
• load_json!

• Assertions can optionally take a path
• Assertions can be composed together w/ the pipe |> operator

defmodule MyProject.ExampleTest
  use ExUnit.Case

  import TestThatJson.Assertions
  import TestThatJson.Helpers

  test "verifying JSON key presence" do
    json = load_json("test/support/json/valid.json") # example helper use

    assert has_json_keys(["key1", "key2"])
  end
end

Test That JSON! has extensive tests, but they're mostly written as ESpec specs because I like that style for complex testing. See the test directory for some basic happy-path tests, and the spec directory for detailed use cases.

1. Add test_that_json as a test-only dependency in mix.exs:

def deps do
  [{:test_that_json, "~> 0.5.0", only: :test}]
end

By default, to avoid needing to know the values of these ahead of time, the following keys are ignored for all JSON objects: id, inserted_at, and updated_at.

This can be reconfigured as follows:

config :test_that_json,
  excluded_keys: ~w(id inserted_at updated_at some other keys)

These are simple strings of "/"-separated object keys and array indexes passed to has_json_path. For instance, with the following JSON:

{
  "first_name": "Jon",
  "last_name": "Snow",
  "friends": [
    {
      "first_name": "Know",
      "last_name": "Nothing"
    }
  ]
}

We could access the first friend's first name with the path "friends/0/first_name".

• Tests
• Docs

• DockYard/json_api_assert
• jonasschmidt/ex_json_schema

Thanks to the creators and maintainers of the Ruby json_spec project for heavy inspiration.

1. Before opening a pull request, please open an issue first.
2. Do the usual fork/add/fix/run tests dance, or whatever tickles your fancy. Tests are highly encouraged.
3. Open a PR.
4. Treat yourself. You deserve it.

See the LICENSE file for license rights and limitations (MIT).