just-tap
JSONAssert
| just-tap | JSONAssert | |
|---|---|---|
| 3 | 2 | |
| 9 | 964 | |
| - | -0.2% | |
| 7.0 | 0.0 | |
| 6 months ago | 8 months ago | |
| JavaScript | Java | |
| MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
just-tap
- Simple lightweight JavaScript test runner that works in the browser and nodejs
-
Stop requiring only one assertion per unit test: Multiple assertions are fine
Yup, it's why I built `just-tap` [1] which trys to minimise as much magic that a lot of these frameworks try to "help" you with.
1. https://github.com/markwylde/just-tap
- Show HN: A JavaScript test runner that works in any JavaScript runtime
JSONAssert
-
Unit Testing Backward Compatibility of Message Format
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.
-
Stop requiring only one assertion per unit test: Multiple assertions are fine
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...