-
Notifications
You must be signed in to change notification settings - Fork 114
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
base: master
Are you sure you want to change the base?
Conversation
@charlierudolph any feedback on this? |
@laserlemon any chance you can merge this or give feedback towards merge? Thanks. |
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 |
@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. |
@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. |
@bglusman I've removed myself as a collaborator on this project so to get this merged will need to tag @laserlemon. |
@laserlemon ping, today's HN stories on OSS contributing reminded me to follow up on this :-) |
@laserlemon ping? Just remembered this still never got merged, reminded by yet another discussion on contributing to open source :-) |
@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. |
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.