RFC: Better Poro Resource Test

[bf4]

Per cerebris/jsonapi-resources-site#45 (comment)
I'm trying to flesh out plain old resource support in JR 0.10.x

Here for comment and if good I'll bring up to standards to be mergeable

All Submissions:

• I've checked to ensure there aren't other open Pull Requests for the same update/change.
• I've submitted a ticket for my issue if one did not already exist.
• My submission passes all tests. (Please run the full test suite locally to cut down on noise from travis failures.)
• I've used Github auto-closing keywords in the commit message or the description.
• I've added/updated tests for this change.

New Feature Submissions:

• I've submitted an issue that describes this feature, and received the go ahead from the maintainers.
• My submission includes new tests.
• My submission maintains compliance with JSON:API.

Bug fixes and Changes to Core Features:

• I've included an explanation of what the changes do and why I'd like you to include them.
• I've provided test(s) that fails without the change.

Test Plan:

Reviewer Checklist:

• Maintains compliance with JSON:API
• Adequate test coverage exists to prevent regressions

[bf4]

hmm

[bf4]

cc @scottgonzalez here's my thinking (btw, test failures seem unrelated)

1. JR doesn't need to support a poro resource, but can document and test one and point people to use that if they wish
2. this refactor at time of comment begins to support a pattern for a poro resource or general subclassing of basic resource
3. next step would either be not to rely on globals in the poro resource to mimic persistence or have two basic resource subclasses 1) non ar persistence 2) non-persisted. The non-persisted one could use technique @scottgonzalez mentioned in problems with 0.10.1 changes to plain old resources  jsonapi-resources-site#45 (comment)

If the resources are not findable (perhaps they do not actually persist), you can store the created model in context in an after_create callback and then return that model in the finder (you can access context via the options argument).

[lgebhardt]

LGTM

The travis failures came in with the introduction of the postgres testing.

[lgebhardt]

@bf4 What do you wish to add to make this mergeable?

[bf4]

@lgebhardt I'm not sure what I might have had in mind when I first wrote the PR. Maybe add more tests around when the various 'NotImplemented' methods are used? I'd like to remove the globals, too. But really, I'm just trying to share what I've learned in trying to use 0.10.x

[lgebhardt]

@bf4 Sounds good, and thanks for the PR. I merged this as is and we can update things later.

[bf4]

xref #1306