What exactly did you do?

Compare <<UNORDERED>> JSON arrays where the elements are objects and the expectation for some fields only checks for <<PRESENCE>>.

Test example:

func TestUNORDEREDwithPRESENCE(t *testing.T) {
	act := `{
		"data": [
			{ "foo": 1, "bar": 2 },
			{ "foo": 11, "bar": 22 }
		]
	}`
	exp := `{
		"data": [
			"<<UNORDERED>>",
			{ "foo": 11, "bar": "<<PRESENCE>>" },
			{ "foo": 1, "bar": "<<PRESENCE>>" }
		]
	}`
	ja := jsonassert.New(t)
	ja.Assertf(act, exp)
}

See test examples with some sanity in this Go Playground.

What did you expect would happen?

The test should pass - I should be able to compare <<UNORDERED>> arrays having elements with <<PRESENCE>> in them.

What actually happened?

=== RUN   TestUNORDEREDwithPRESENCE
    prog.go:81: actual JSON at '$.data[0]' contained an unexpected element: {"bar":2,"foo":1}
    prog.go:81: actual JSON at '$.data[1]' contained an unexpected element: {"bar":22,"foo":11}
    prog.go:81: expected JSON at '$.data[0]':
        {"bar":"\u003c\u003cPRESENCE\u003e\u003e","foo":11}
        was missing from actual payload
    prog.go:81: expected JSON at '$.data[1]':
        {"bar":"\u003c\u003cPRESENCE\u003e\u003e","foo":1}
        was missing from actual payload
--- FAIL: TestUNORDEREDwithPRESENCE (0.00s)
FAIL

Additional info

• Output from go version: go version go1.18.2 darwin/arm64
• Version of this package: v.1.1.0

As can be seen in the Go Playground example, I did some sanity tests, and it seems that <<UNORDERED>> and <<PRESENCE>> work well for the example above, except for when they are mixed together.
Looking in the code, it seems to be caused by. the difference between Asserter.checkArrayUnordered and Asserter.checkArrayOrdered. The unordered version uses Asserter.deepEqual, whereas the ordered version uses Asserter.pathassertf.

Hi, thanks for the package.
I had a particular use case using a testing library and did a quick and messy fork to prove the concept on a fork.
This might be outside the scope or your vision of the project which is completely fine.
I could see others having a similar issue with any testing framework, and adding this flexibility might increase adoption

What problem are you trying to solve?

Use JSON comparison features without involving testing.T
I'm using a testing/assertion library that does not check JSON structure well (Go Convey). I'd like to use the reporter of the testing library instead fo directly on testing.T

Describe how you wish this package would help you solve the problem

I'd like access to a comparison function that takes the same signature as the Assertf() method and returns an error or nil

Example

I have done a quick proof-of-concept for my needs at this fork: ryanlelek/jsonassert.
This involved a lot of copy/paste and removal of the method on (a *Asserter)
You could probably split the comparison out similar to how I did and then wrap in a method for (a *Asserter)
Here's how I'm able to use within testing framework

err := jsonassert.Assert(res.BodyString, `{
    "format": "json",
    "data": "example"
}`)
So(err, ShouldBeNil)

Then I can check the value of err within the testing framework

What problem are you trying to solve?

If the comparison fails, it could be interesting to be able to print the failed/expected JSON. With the current implementation it's not trivial detecting the assertion failure.

Describe how you wish this package would help you solve the problem

if !jsonassert.New(t).Assertf(expected, current) {
    ... print JSON ...
}

// or better yet
if !jsonassert.Equal(t, expected, current) {
     ...
}

What exactly did you do?

ja.Assertf(`{"test":"A%AAA%BBBB%CC"}`, `{"test":"A%AAA%BBBB%CC"}`)

I think this happens because the fmt.Sprintf used in the package

What did you expect would happen?

I expect assert pass in this situation
my guess is on the fmt.Sprintf used in Assertf function, It identifies the %char as some unsupported formatter

What actually happened?

Assertf format %A has unknown verb A

Additional info

• Output from go version: go version go1.15.13 darwin/amd64
• Version of this package: v1.0.1

Some properties of a JSON payload may be difficult to know in advance. E.g. a timestamp or a UUID or other randomly assigned values.

Proposition

Allow for a string: "<<PRESENCE>>" to not be interpreted literally, but when found in the expected JSON, only check that there is some value for this key in the actual JSON.

If the expected JSON is:

{
  "foo": "<<PRESENCE>>"
}

Then all of the below payloads will match, assuming it is still valid JSON.

{"foo": ""}`
{"foo": {"baz": "bar"}}
{"foo": [1,3, "bar"]}

However, the following payloads should fail.

{"foo": null}
{"foo": "25}

Approach

• Look for the "<<PRESENCE>>" keyword
• Still check for valid JSON even if the expected keyword is "<<PRESENCE>>"
• Update the README
• Update godocs

What problem are you trying to solve?

I understand that this is an assertion tool and not a snapshotting tool, but it's the best choice for asserting that the JSON returned from an API call is correct, and in general it works fantastically for this.

However, it is slightly clunky when you are first writing a test. Unless you know exactly what the JSON should look like, you either need to generate it manually and paste into the test or else go through one value at a time fixing up errors until the test passes. Both of which are awkward.

(And yes, I'm aware this is slightly lazy, but it's super convenient especially when there's a lot of large JSON responses to check)

Describe how you wish this package would help you solve the problem

It would be fantastic if there were some way that the library could output the full actual JSON in some cases. Maybe if the expected JSON were just the blank string, for example.

That way you could write a test of

	ja.Assertf(string(body), ``)

Run the test, copy the output JSON into the test and know that it's correct.

Setting up the repository

This document serves as both a list of all the rules and steps to set up a very good open source Go project, and also the issue contents of the GitHub issue generated by github.com/kinbiko/go-template's astroturf.sh script that automates a bunch of these very steps.

CI

• Builds against one of the 2 latest Go versions
• Has golangci-lint v1.45.2 passing
• Runs tests with the race detector
• Runs integration tests, if applicable
• Reports coverage to coveralls
• Code scanning with CodeQL

Community Standards

• Description w/ tags
• README
• Code of conduct
• Contributing guideline
• License
• Issue template(s)
• Pull request template
• CODEOWNERS

GitHub settings

• Wiki pages disabled
• Sponsorship enabled
• Projects disabled (my OSS work is managed in a central project board)
• GitHub archive program enabled
• Discussions disabled
• Merge commits disabled
• Squash merging enabled
• Rebase merging disabled
• Suggest updating branches enabled
• Auto-merge disabled
• Auto-delete head branches enabled
• Limit "approve" or "request changes" to users with explicit permissions
• Default branch is main, with the following branch protection rules enabled (everything else disabled):
  • Require PRs before merging (no approvals required, don't dismiss PR approvals on new commits, don't require codeowner review)
  • Linear history enabled (assumption: only enabling squash merges globally means linear history in default branch)
• Allow kinbiko and select non-kinbiko actions only:
  • Allow actions created by GitHub enabled
  • Allow actions by Marketplace verified creators enabled
  • shogo82148/actions-goveralls@v1 added as allowed action
• Require approval before running actions for first-time contributors
• GitHub actions approving PRs disabled
• Dependabot alerts enabled for security vulns
• Dependabot updates enabled for security vulns
• Code scanning (CodeQL) enabled
• Consistent labels:
  • bug
  • dependencies
  • documentation
  • enhancement
  • good first issue
  • help wanted
  • question

README

• Has tags:
  • Build status
  • Coverage percentage
  • Go report link
  • Latest version
  • Godoc with link to pkg.go.dev
  • License tag
• Explains the why and then the what.
• Usage information incl any installation guidelines
• Link to docs

It would be nice if you could slurp a json schema spec in and just match against that...

What problem are you trying to solve?

It's not possible to use this package to make assertions against payloads that have arrays that aren't deterministic in their ordering.

Describe how you wish this package would help you solve the problem

Expose a directive similar to <<PRESENCE>> that can be added as the first element of the array in order to ignore ordering.

// should pass
ja.Assertf(`["foo", "bar"]`, `["<<UNORDERED>>", "bar", "foo"]`)

References

This issue was created based on the request from @blaskovicz on #25.

What exactly did you do?

Tried to use <<UNORDERED>> in side a payload with an array complains length doesn't match

ja.Assertf(string(body), `
	{
		"code":200,
		"revenue":[
			"<<UNORDERED>>",
			{"date":"2020-10-01","value":100.01},
			{"date":"2020-10-02","value":200.01}
		]
	}`)

What did you expect would happen?

It would work and validate the json

What actually happened?

    overall_structs_test.go:57: length of arrays at '$.revenue' were different. Expected array to be of length 3, but contained 2 element(s)
    overall_structs_test.go:57: actual JSON at '$.revenue' was:
        [{"date":"2020-10-01","value":100.01},{"date":"2020-10-02","value":200.01}]
        but expected JSON was:
        ["\u003c\u003cUNORDERED\u003e\u003e",{"date":"2020-10-01","value":100.01},{"date":"2020-10-02","value":200.01}]

Additional info

• Output from go version: [e.g. go version go1.14.5 darwin/amd64] go version go1.17.4 darwin/amd64
• Version of this package: [e.g. v.1.0.2] v1.0.2

Hello. First of all, great package!
It really reduces boilerplate code in tests and makes everything more readable.

I have a feature request/consideration I hope would get included to this project and I may help implement it if that's something that makes sense for this library: Partial JSON matching.

It can be behind a flag or in another method, but it basically means a JSON with 4 properties, when checked against a JSON with 2 properties, would not return the following error:

expected 2 keys at '$' but got 4 keys
unexpected object key(s) ["status","cause"] found at '$'

More often than not, we need to check for the overall structure and main fields and not the whole thing, and having to check for presence of every single field can take a lot of time.

Is this something that makes sense for you as the author of this library?
As much as I like creating my own fork, I think it's best for the community if we keep things centralized.

Thanks.