Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Contains feature #25

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Support Contains feature #25

wants to merge 14 commits into from

Conversation

kinbiko
Copy link
Owner

@kinbiko kinbiko commented Mar 7, 2021

Closes #20

  • Adds Containsf API
  • Removes silly panic.
  • Implements an "<<UNORDERED>>" feature to ignore ordering in arrays.

TODO:

  • Buggy: Commented-out test still fails -- will return to fixing it at some point.
  • Self-review
  • Consider releasing an alpha/beta version.
  • Tidy up commits.
  • Judge whether to commit to introducing this new feature, or to drop it for simplicity.

@kinbiko
Copy link
Owner Author

kinbiko commented Mar 13, 2021

Starting to think that may be a <<PARTIAL>> directive in each of the collection types would result in a less confusing API.
Exposing a top level method for checking a payload partially doesn't work neatly with nested structures, since it's not clear if the partiality applies to the top level or the nested data as well.
Also, for bigger payloads that might span an entire screen when pretty-printed, it's friendlier to see <<PARTIAL>> reminders closer to the things that are being checked partially, and not for the others.

I'm thinking it could work something like this:

jsonassert.Assertf(payload, `{
	"nested": {
		"<<PARTIAL>>": "Value doesn't matter, but let's establish a boolean convention",
		"thisNestedObject": "can have additional keys in the payload and still pass the test"
	},
	"anotherNested": {
		"thisOtherNestedObject": "is checked for unexpected keys"
	},
	"thisOuterObject": "is also checked for unexpected keys"
}`)

and for arrays it would work like:

jsonassert.Assertf(payload, `{
	"someArr": [
		"<<PARTIAL>>",
		"the above directive must be the first in the array",
		"and if present the existence of the following values",
		"irrespective of order",
		"is all that's checked."
		"i.e. <<PARTIAL>> can be used for both...",
		"- checking for that *one element* out of 100",
		"- and checking for unordered arrays"
	]
}`)

as I'm writing this I'm convincing myself that I should probably implement some sort of ordering check independently of this feature first, as the above solution would pass even if there were unexpected elements in an unordered array.

@blaskovicz
Copy link

blaskovicz commented Aug 19, 2021

I love the idea of

Implements an "<<UNORDERED>>" feature to ignore ordering in arrays.

Some of the APIs i'm testing against don't have deterministic ordering, so i've had to hack around this with unmarshal/sort/marshal/compare logic.

@blaskovicz
Copy link

blaskovicz commented Aug 19, 2021

Thank you for the excellent library and all the hard work!

Another way which we could approach this problem is to allow interfaces to be passed. This could allow golang tags to be used for extra metadata to apply during a match. For example

type MatcherOutput struct {
        FieldA []string `json:"field_a" jsonassert:"unordered"`
        ...
}

@kinbiko kinbiko mentioned this pull request Aug 21, 2021
@kinbiko
Copy link
Owner Author

kinbiko commented Aug 21, 2021

@blaskovicz This PR is probably not going to land soon (chances are I'll rewrite it), but if you want you can check if v1.1.0-beta suits your needs.
If you're feeling generous, feedback in the form of a comment under #31 would be highly appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: support for partial JSON matching
2 participants