Helpers for a better JSON testing experience in Elixir.
Using ESpec? Check out test_that_json_espec.
For now, see the Json module for docs for much of the API.
This project has an extensive test suite, so see that for detailed usage.
-
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_size -
has_json_type -
is_json_equal -
load_json -
load_json! -
parse_json -
parse_json! -
prettify_json -
prettify_json! -
to_json -
to_json! -
to_prettified_json -
to_prettified_json!
- Helpers that return a boolean can optionally take a path
- Helpers can be composed together w/ the pipe |> operator
defmodule MyProject.ExampleTest
use ExUnit.Case
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
endTest 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.
- Add
test_that_jsonas a test-only dependency inmix.exs:
def deps do
[
{:test_that_json, "~> 0.6.0", only: :test},
]
endBy 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 for entire helper API
Thanks to the creators and maintainers of the Ruby json_spec project for heavy inspiration.
- Before opening a pull request, please open an issue first.
- Do the usual fork/add/fix/run tests dance, or whatever tickles your fancy. Tests are highly encouraged.
- Open a PR.
- Treat yourself. You deserve it.
See the LICENSE file for license rights and limitations (MIT).