Write JSON unit tests in less code. Great for testing REST interfaces.

Related tags

JSON JSONassert
Overview

JSONassert

Write JSON unit tests in less code. Great for testing REST interfaces.

Summary

Write JSON tests as if you are comparing a string. Under the covers, JSONassert converts your string into a JSON object and compares the logical structure and data with the actual JSON. When strict is set to false (recommended), it forgives reordering data and extending results (as long as all the expected elements are there), making tests less brittle.

Supported test frameworks:

Examples

In JSONassert you write and maintain something like this:

JSONObject data = getRESTData("/friends/367.json");
String expected = "{friends:[{id:123,name:\"Corby Page\"},{id:456,name:\"Carter Page\"}]}";
JSONAssert.assertEquals(expected, data, false);

instead of all this:


JSONObject data = getRESTData("/friends/367.json");
Assert.assertTrue(data.has("friends"));
Object friendsObject = data.get("friends");
Assert.assertTrue(friendsObject instanceof JSONArray);
JSONArray friends = (JSONArray) friendsObject;
Assert.assertEquals(2, data.length());
JSONObject friend1Obj = friends.getJSONObject(data.get(0));
Assert.true(friend1Obj.has("id"));
Assert.true(friend1Obj.has("name"));
JSONObject friend2Obj = friends.getJSONObject(data.get(1));
Assert.true(friend2Obj.has("id"));
Assert.true(friend2Obj.has("name"));
if ("Carter Page".equals(friend1Obj.getString("name"))) {
    Assert.assertEquals(123, friend1Obj.getInt("id"));
    Assert.assertEquals("Corby Page", friend2Obj.getString("name"));
    Assert.assertEquals(456, friend2Obj.getInt("id"));
}
else if ("Corby Page".equals(friend1Obj.getString("name"))) {
    Assert.assertEquals(456, friend1Obj.getInt("id"));
    Assert.assertEquals("Carter Page", friend2Obj.getString("name"));
    Assert.assertEquals(123, friend2Obj.getInt("id"));
}
else {
    Assert.fail("Expected either Carter or Corby, Got: " + friend1Obj.getString("name"));
}

Error Messages

We tried to make error messages easy to understand. This is really important, since it gets hard for the eye to pick out the difference, particularly in long JSON strings. For example:

String expected = "{id:1,name:\"Joe\",friends:[{id:2,name:\"Pat\",pets:[\"dog\"]},{id:3,name:\"Sue\",pets:[\"bird\",\"fish\"]}],pets:[]}";
String actual = "{id:1,name:\"Joe\",friends:[{id:2,name:\"Pat\",pets:[\"dog\"]},{id:3,name:\"Sue\",pets:[\"cat\",\"fish\"]}],pets:[]}"
JSONAssert.assertEquals(expected, actual, false);

returns the following:

friends[id=3].pets[]: Expected bird, but not found ; friends[id=3].pets[]: Contains cat, but not expected

Which tells you that the pets array under the friend where id=3 was supposed to contain "bird", but had "cat" instead. (Maybe the cat ate the bird?)


QuickStart

To use, download the JAR or add the following to your project's pom.xml:

<dependency>
    <groupId>org.skyscreamer</groupId>
    <artifactId>jsonassert</artifactId>
    <version>1.5.0</version>
    <scope>test</scope>
</dependency>

Write tests like this:

JSONAssert.assertEquals(expectedJSONString, actualJSON, strictMode);

More examples in our cookbook


Who uses JSONassert?


org.json

This implementation uses a clean-room implementation of the org.json library implemented for the Android system, released under the Apache 2.0 license. See com.vaadin.external.google:android-json That jar does not include the org.json.JSONString interface, so a new implementation of that interface is added to this source.

Resources

JavaDoc

Comments
  • Update version of org.json

    Update version of org.json

    As @hertzsprung pointed out, we're running an ages-old version of org.json. We're looking into helping them update the version they have in maven. If that doesn't work, we may need to either fork it ourselves, or look at other libraries. (We chose org.json for it's simplicity and lack of additional dependencies, so we'd like to stick with it if possible.)

    opened by carterpage 12
  • Fix numerical comparisons

    Fix numerical comparisons

    If a field appears to be an integer, and a double of the same value appears, JsonAssert reports something like:

    Values of geo.coordinates[0] have different types: expected java.lang.Integer, but got java.lang.Double ; Values of geo.coordinates[1] have different types: expected java.lang.Integer, but got java.lang.Double

    In this case, the value expected value is 0 (an integer) and the given value is 0.0 (a double).

    The key observation is that the double can be coerced into the integer without loss of precision, and therefore should be allowed.

    opened by derrickburns 10
  • fixes for issues 60 and 65 compare of Arrays of Json objects. could not identify mismatches in nth array.

    fixes for issues 60 and 65 compare of Arrays of Json objects. could not identify mismatches in nth array.

    the comparison for arrays used an arbitrary field and then used the VALUE of the field as the hash key to lookup in the actual array object.. this gave a misleading error.. as the fiield existed, but had a different value. the error should report the total mismatch

    opened by sdetweil 9
  • nōn-free json.org code used

    nōn-free json.org code used

    Hi,

    my coworkers want to use JSONassert in their project, but (as the person responsible for insisting on proper licences) I need to tell them not to, because your code pulls in code from json.org under Douglas Crockford’s bad licence.

    Please replace this; the Debian Wiki page https://wiki.debian.org/qa.debian.org/jsonevil contains background information and a list of alternative implementations. Apparently, https://android.googlesource.com/platform/libcore/+/master/json is a drop-in replacement. I asked a coworker (@tkrille) whether it would be possible to just write a pom.xml file for http://ftp.de.debian.org/debian/pool/main/liba/libandroid-json-org-java/libandroid-json-org-java_20121204-20090211.orig.tar.gz and upload that to Maven Central. It appears to be (note: I’m not a Java™ developer myself) a drop-in replacement, so you’d “just” have to change the reference in your own pom.xml afterwards (and test).

    Would also be nice if you could do that yourself.

    Thanks for your consideration!

    opened by mirabilos 9
  • Fork: Use Jackson instead of org.json

    Fork: Use Jackson instead of org.json

    We have a toolchain based on Jackson; I'd like to use JSONassert with Jackson JSON objects. I've forked the skyscreamer/JSONassert repo and replaced org.json with FasterXML/jackson-core and FasterXML/jackson-databind.

    The biggest hurdle is the unit tests; Jackson is more strict and does not allow unquoted object names and unquoted values; but requires double quotes. This requires updating all the unit tests to use quoted names/values such as

    {"a":[{"background":"white","id":1,"type":"row"} ...
    

    instead of

    {a:[{background:white,id:1,type:row}
    

    (While Jackson has Feature.ALLOW_UNQUOTED_FIELD_NAMES, it does not have a Feature to allow unquoted values.)

    My real question is: is that fork reasonable to push back to skyscreamer/JSONassert, perhaps in a different branch, or would it be better to push the fork elsewhere as a separate project (because current users of skyscreamer/JSONassert may depend on using unquoted strings)? If I do publish a different fork on GitHub, would you prefer I change the package names as well? I would certainly provide attribution to skyscreamer/JSONassert as the base of the fork, and release it under the same Apache 2.0 license.

    thanks.

    opened by DavidBiesack 6
  • Added a MANIFEST.MF file so that the jar can be used directly in OSGi

    Added a MANIFEST.MF file so that the jar can be used directly in OSGi

    Added a MANIFEST.MF file so that the jar (built in the usual way with maven) can be used directly in OSGi - so for example you can use it as an eclipse bundle dependency in your target platform for running junit tests.

    Also added some gitignore entries to not pollute the repo. with eclipse project specific files but still be able to use it in eclipse.

    opened by costescuandrei 5
  • Fixes #42 - overloaded methods to accept a message

    Fixes #42 - overloaded methods to accept a message

    • Overloaded equals() ans notEquals() methods to accept a message
    • Junits for all the possible new overloads
    • improvements in some of the existing junits
    opened by yasin3061 5
  • Add message to JSONAssert

    Add message to JSONAssert

    I would love to be able to include a message to JSONAssert.assertEquals in the beginning of the method invocation:

    assertEquals("expected should equal actual", expected, actual, false);
    
    opened by paolodm 5
  • Jsonpath

    Jsonpath

    baseline implementation of jsonpath customizations.

    Allows to specify custom matchers for specific jsonpaths. It does not support bracket notation, wildcards, array indexing or slicing, filters, and any other advanced jsonpath expression.

    opened by albx79 5
  • Changes to dependencies for cleanliness in Android

    Changes to dependencies for cleanliness in Android

    Not sure if you want this, but the commons-collections dependency is kind of unruly and seemed unnecessary to me. I also changed the org.json version to be the one included with Android so that there aren't version conflicts when this is used with Android.

    opened by billmag 5
  • Enhance JSONCompareMode enum

    Enhance JSONCompareMode enum

    A couple more helper methods I'm using in my hamcrest matchers, as well as some javadoc fixes.

    I could also add withoutExtensibility() and butStrict() just for symmetry. I'm also not 100% sure about the method names?

    opened by hertzsprung 5
  • Modularization (JPMS)

    Modularization (JPMS)

    Hi,

    I really appreciate this project but, as already noted in other open issues (#116, #122), it needs to move to modularity in order to be on a level with modern java and, in the process, fix some related issues:

    • com.vaadin.external.google:android-json dependency smells like a forgotten wreck (no update since 2014, no clear maintainer (does it even have a public repo?), no foreseeable support to modularity...) which should be replaced with an up-to-date alternative (e.g. openjson, cited here, looks promising)
    opened by stechio 0
  • Move JSONString out of split package

    Move JSONString out of split package

    This removes the org.json package as it's a split package with the one in android-json, fixing usages in the module system introduced in Java 9.

    JSONString has been moved to org.skyscreamer.jsonassert. As far as I can tell, the reason this was in a split package to begin with is to allow JSONString implementers to have access to package-private methods in android-json's org.json.

    The package-private methods/fields are:

    • JSONStringer
      • JSONStringer(int indentSpaces)
      • JSONStringer open(Scope empty, String openBracket)
      • JSONStringer close(Scope empty, Scope nonempty, String closeBracket)
      • final StringBuilder out
      • enum Scope
    • JSON
      • static double checkDouble(double d)
      • static Boolean toBoolean(Object value)
      • static Double toDouble(Object value)
      • static Integer toInteger(Object value)
      • static Long toLong(Object value)
      • static String toString(Object value)
    • JSONObject
      • String checkName(String name)
      • void writeTo(JSONStringer stringer)
    • JSONArray
      • void writeTo(JSONStringer stringer)

    So if you wanted to create your own "JSONThing", these methods are clearly pretty useful. I don't know how common it is to do this, but I imagine most consumers are just using JSONAssert, like Spring does. I'd argue that anyone using these package-private methods is skilled enough to just make them accessible via reflection, so while this is a breaking change, I don't think it's that bad.

    Given it is a breaking change however, maybe this PR can be targeted to a 2.0 release? I'm not sure how committed you are to semantic versioning, but I'm pretty indifferent as long as this gets merged :). Thanks!

    opened by zrbrown 1
  • add GitHub Actions workflow to verify builds and pull requests

    add GitHub Actions workflow to verify builds and pull requests

    This is a pipeline example for using GitHub Actions workflows to verify builds and PRs.

    It's based on a matrix build for all Temurin LTS versions currently available. Some modifications to the pom.xml were necessary:

    • update the compiler plugin
    • add two additional auto-activated profiles that set the expected compiler options for source/target and release respectively

    I tried building a secondary job for JDK 1.6, however, couldn't find a URL to an OpenJDK 1.6 version. I am wondering how they do that over at org.json:json with their pipeline?!

    opened by Okeanos 1
  • Input not validated to be valid JSON, inconsistent behaviour on certain number values

    Input not validated to be valid JSON, inconsistent behaviour on certain number values

    I just saw that we have unit tests in a project that test JSONassert because of the inconsistent behaviour. I will abstain from explaining why unit tests (especially those with edge cases) are important to get correct and consistent code. Instead I just report the problems I found here.

    One thing is that NaN seems to be allowed sometimes but rejected in other cases. I know that at least new JSONArray with NaN inside it works and JSONAssert even thinks that it could be equal, even thought NaN != NaN. It should always throw an exception, as it does sometimes.

    Another problem is with numbers that start with 0. JSON doesn't allow it but JSONassert sometimes interprets it is octal, and sometimes just ignores the 0. Instead it should reject any number that starts with 0 unless it's actually 0 ("Unexpected number in JSON at position ...").

    It's also weird that integers and fractions are not the same. The reason is probably because the JSON specs have different grammar rules for the two but in the end it's always just a "number". So 1 is the same as 1.0. Therefore [1] is equal to [1.0]. But somehow JSONassert is inconsistent when it comes to comparing numbers. There are no true integers in ECMAScript, so why does it even use different types in Java for those? It should just store them all as Double. Or possibly as BigDecimals. I dind't get into the comparing of numbers that are too close together to distinguish using 64bit floating point numbers. For that one would use strings anyway and I'd expect them to be equal if the numbers are equal. But are those two JSON expressions equal: {foo: -0.0} {foo: 0.0} I would say they are. JSONassert disagrees. But as soon as the numbers are inside an array they suddenly are equal. This inconsistency is clearly not correct.

    opened by claudemartin 0
  • Asserting softly

    Asserting softly

    Currently, if I use JSONAssert.assertEquals(...) and if there's an assertion error, AssertionError will be thrown and the code will exit. However, I want my TestNG @Test to do this in loop for several data sets and collect all the assertion errors and throw AssertionError is there are one or more assertion errors (similar to TestNG's SoftAssert). Do note that using a DataProvider is not feasible since I'm using it already for injecting a higher level of test data.

    Is there a way I could use this JSONAssert library to assert softly?

    opened by akshayamaldhure 0
Releases(jsonassert-1.5.1)
MapNeat is a JVM library written in Kotlin that provides an easy to use DSL (Domain Specific Language) for transforming JSON to JSON, XML to JSON, POJO to JSON in a declarative way.

MapNeat is a JVM library written in Kotlin that provides an easy to use DSL (Domain Specific Language) for transforming JSON to JSON, XML to JSON, POJ

Andrei Ciobanu 59 Sep 17, 2022
Compare JSON in your Unit Tests

JsonUnit JsonUnit is a library that simplifies JSON comparison in tests. APIs AssertJ integration Hamcrest matchers Spring MVC assertions Spring WebTe

Lukáš Křečan 719 Dec 29, 2022
Java Concolic Unit Testing Engine

jCUTE The Java Concolic Unit Testing Engine (jCUTE) automatically generates unit tests for Java programs. Concolic execution combines randomized concr

Open Systems Laboratory 81 Nov 7, 2022
JSON to JSON transformation library written in Java.

Jolt JSON to JSON transformation library written in Java where the "specification" for the transform is itself a JSON document. Useful For Transformin

Bazaarvoice 1.3k Dec 30, 2022
Generate Java types from JSON or JSON Schema and annotates those types for data-binding with Jackson, Gson, etc

jsonschema2pojo jsonschema2pojo generates Java types from JSON Schema (or example JSON) and can annotate those types for data-binding with Jackson 2.x

Joe Littlejohn 5.9k Jan 5, 2023
Essential-json - JSON without fuss

Essential JSON Essential JSON Rationale Description Usage Inclusion in your project Parsing JSON Rendering JSON Building JSON Converting to JSON Refer

Claude Brisson 1 Nov 9, 2021
A simple java JSON deserializer that can convert a JSON into a java object in an easy way

JSavON A simple java JSON deserializer that can convert a JSON into a java object in an easy way. This library also provide a strong object convertion

null 0 Mar 18, 2022
A 250 lines single-source-file hackable JSON deserializer for the JVM. Reinventing the JSON wheel.

JSON Wheel Have you ever written scripts in Java 11+ and needed to operate on some JSON string? Have you ever needed to extract just that one deeply-n

Roman Böhm 14 Jan 4, 2023
An Engine to run batch request with JSON based REST APIs

JsonBatch An Engine to run batch request with JSON based REST APIs Some usecase for this library: Provide a batch API to your REST API set. Quickly ro

Rey Pham 11 Jan 3, 2022
Benchmark testing number reading/writing in Java.

double-reader-writer Benchmark testing number reading/writing in Java. Relates to FasterXML/jackson-core#577 So far, FastDoubleParser looks useful if

PJ Fanning 2 Apr 12, 2022
Java friendly DSL for defining TestFX tests

TestFX-DSL aims to bring DSL capabilities on top of TestFX. Inspired by Geb, this DSL enables a fluent interface design on top of the facilities exposed by TestFX.

Andres Almiray 5 Aug 21, 2019
High performance JVM JSON library

DSL-JSON library Fastest JVM (Java/Android/Scala/Kotlin) JSON library with advanced compile-time databinding support. Compatible with DSL Platform. Ja

New Generation Software Ltd 835 Jan 2, 2023
A Java serialization/deserialization library to convert Java Objects into JSON and back

Gson Gson is a Java library that can be used to convert Java Objects into their JSON representation. It can also be used to convert a JSON string to a

Google 21.7k Jan 8, 2023
High-performance JSON parser

HikariJSON A High-performance JSON parser. HikariJSON is targeted exclusively at Java 8. If you need legacy support, there are several decent librarie

Brett Wooldridge 454 Dec 31, 2022
Screaming fast JSON parsing and serialization library for Android.

#LoganSquare The fastest JSON parsing and serializing library available for Android. Based on Jackson's streaming API, LoganSquare is able to consiste

BlueLine Labs 3.2k Dec 18, 2022
A modern JSON library for Kotlin and Java.

Moshi Moshi is a modern JSON library for Android and Java. It makes it easy to parse JSON into Java objects: String json = ...; Moshi moshi = new Mos

Square 8.7k Dec 31, 2022
A fast JSON parser/generator for Java.

fastjson Fastjson is a Java library that can be used to convert Java Objects into their JSON representation. It can also be used to convert a JSON str

Alibaba 25.1k Dec 31, 2022
JSON query and transformation language

JSLT JSLT is a complete query and transformation language for JSON. The language design is inspired by jq, XPath, and XQuery. JSLT can be used as: a q

Schibsted Media Group 510 Dec 30, 2022
Sawmill is a JSON transformation Java library

Update: June 25, 2020 The 2.0 release of Sawmill introduces a breaking change to the GeoIpProcessor to comply with the updated license of the MaxMind

Logz.io 100 Jan 1, 2023