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

Match nested json without a specific path #75

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

bglusman
Copy link

This has some things in common with #64 but It's a little bit more flexible and less rigid an option, for when you don't want to over-specify the path to the json, but simply want to test it's presence somewhere in the structure. It's implemented as a subclass of IncludeJson, and it passes all the same tests plus a few new ones, but sharing the tests would look ugly with the different method names, and be unDRY copy pasted. I had them copied before and pulled out in a subsequent commit. If there's a better solution happy to tackle it, or if you want the shared tests back in we can revert a04618e.

@bglusman
Copy link
Author

@charlierudolph any feedback on this?

@bglusman
Copy link
Author

@laserlemon any chance you can merge this or give feedback towards merge? Thanks.

@charlierudolph
Copy link

I'm personally not a big fan of this matcher. It's too powerful and doesn't make you define your specifications with enough detail. I would hate seeing the test description it "includes {a: 'b'} anywhere in the response". To me that's just not useful. What benefits do you see in having this?

@bglusman
Copy link
Author

@charlierudolph Hey charlie... having written a lot of hypermedia API's, some of which have embedded/nested resource representations, mostly I see it as a question of non-brittleness, in the face of changing resources. The details of the parent's other attributes may change, and or the specific path the the embedded resource may be encoded in the parent. Detail is important, except when it isn't, or when it makes you specify things the way they are now and then repeatedly change them every time the behavior evolves without the actual behavior under test changing.

@bglusman
Copy link
Author

@charlierudolph just checked back and see no response, but to expand a bit, realistically in the hypermedia example, the use case is probably not saying 'json literal is anywhere in the response' but more 'model.to_json is anywhere in the response', for doing acceptance testing on an API that should return the model's json, but might do it in various different json schema formats or as part of a collection in an arbitrary location inside an array of other models json representations. In case that helps to clarify/justify.

@charlierudolph
Copy link

@bglusman I've removed myself as a collaborator on this project so to get this merged will need to tag @laserlemon.

@bglusman
Copy link
Author

bglusman commented Dec 7, 2014

@laserlemon ping, today's HN stories on OSS contributing reminded me to follow up on this :-)

@bglusman
Copy link
Author

@laserlemon ping? Just remembered this still never got merged, reminded by yet another discussion on contributing to open source :-)

@bglusman
Copy link
Author

bglusman commented Aug 5, 2015

@laserlemon shall I just close this? edit: I see there's been no activity in the last 10 months, so I guess it can just sit here until someone is ready to take a look, just kind of felt ignored, but I guess it's really the project that's been ignored.

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.

2 participants