Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Compliance test suite #1209
This topic has been brushed a few times already (#1098, #892, #733). The idea is to provide a test suite so that library implementers can 1. prove compliance to the spec and 2. uniformly showcase their abilities.
I went ahead and created some basic infrastructure: jsonapi-grader, which is mainly a bunch of request specs.
The idea with the validation of server libraries is that each maintainer would set up a service (on a free heroku instance or similar) against which users could run the test suite (and possibly the jsonapi.org maintainers would periodically run it as well). The test scenarii would possibly be documented on the jsonapi.org website.
Making it happen
Sounds interesting? Get involved and help build the actual test suite (suggesting scenarii and/or implementing them).
referenced this issue
Aug 4, 2017
Since this is the new home for this discussion I'll bring my recommendation here from #1098
I'm proposing we use 'Author > Books > Reviews' as the basis of an example app.
Lets make it so that all resources in the domain have names that are very easy to grok and can not be in any way misunderstood for code related terms.
@evolve2k Thanks for the input. I agree that we should keep the test scenarii and the tested resources/endpoints simple to reason about.
@fotinakis I'm not certain we should be concerned with the casing choice of the Server since, although it is a recommendation, is not required. For example, an implementation may only support camelCased or snake_cased names. Compound resource names introduce, what I would consider to be, an unnecessary complexity. It makes result validation a bit more complicated since now we need to check the keys of the returned document against several different casing options. But, I also see the value in being able to state what casing mode the Server uses by default. If we did use compound names, I believe it should be isolated to a single test, validating ONLY that.
Partial test suite here as well: https://github.com/endpoints/endpoints/tree/master/test/integration