JUnit VS JSONAssert

Because I only wanna use the cmd java test, so I chose Junit4 which supports Plain-old JAR. I did test according to the Getting started document. But when I ran the javac -cp .:junit-4.XX.jar:hamcrest-core-1.3.jar CalculatorTest.java I got the error message CalculatorTest.java:4: error: package main does not exits. I tried to reorganize the folder and set Path according to others' experience 1, 2, but it still did not work.

Oops, another error. This is why we should read the manual 😅.

JUnit4

Delete those imports and remove the junit-jupiter-api dependency. Follow the instructions for JUnit 4.

Quite a lot of Java dependencies bring Junit 4 or Junit vintage engine as a transitive dependency.

The AHTest039.json file is the actual test. My testRunner() method (no relation to JUnit test runners) reads that JSON file, processes it, and asserts that the test passed. So my test class consists of a few Java methods, and what is essentially a list of JSON files to process.

And finally, we check that the supplied json equals to the one we got on step 3 (I use JSONAssert library here). The false boolean parameter tells to check only overlapping fields. For example, if the actual result contains the addressV2 field and the expected object doesn’t, it won’t trigger the failure. That’s a normal situation because backward compatibility data is static while the OrderCreated might grow with new parameters.

This can be improved, it'd be worth Googling for a better solution than what you have.

https://github.com/skyscreamer/JSONassert seems decent.

but it can be done from scratch in a few hours (I'd recommend this if you have 'standardized' fields which you may want to ignore):

1) Move to a matcher library for assertions (Hamcrest is decent), and abstract `toJSON` into the a matcher, rather on the input.

This would change the assertion from:

`assertEquals(toJson(someObject), giantJsonBlobFromADifferentFile)`

to:

`assertThat(someObject, jsonEqual(giantJsonBlobFromADifferentFile))`

The difference here is subtle: it allows `jsonEqual` to control the formatting of the test failure output, so on a failure you can:

* convert both of the strings back to JSON

* perform a diff, and provide the diff in the test output.

Decent blog post on the topic: https://veskoiliev.com/use-custom-hamcrest-matchers-to-level...