sinopia server testing

[jmartin-sul]

• [x] investigate ways to test that sinopia server (i.e. trellis-ext-db and our augmentations to it) correctly implements the LDP operations we care about.
• [x] start writing some tests

[jmartin-sul]

the plan is to use swagger-codegen to generate a JS client from the swagger.yaml. we hope to use this client code both for talking with sinopia server/trellis IRL, and for writing integration tests against the server.

open questions:

• [x] how do we spin up the server automatically for testing, e.g. using a CI service like travis or circle? maybe we could leverage some of the gradle tasks in trellis or trellis-ext-db to spin up a server instance for testing? maybe the trellis test code can provide some integration-y testing examples?
  • [x] do we need to seed some known test data in our test trellis-ext-db instance?
• [x] do we need to write any more client code (not for testing)? or does swagger-codegen provide us with a fully implemented client that we can use?
• [ ] if/when the swagger spec changes, what's a sane strategy for regenerating the client code and updating the tests as needed?

other things that were considered, but that we're passing on:

• we'd briefly discussed kotlin as a language for testing trellis, but i'd lean against that. we're short on time, and it's yet another new tool/language we'd have to learn. and it has some unfamiliar constructs (e.g. classes are closed by default). prob too much of a learning curve for the time we have.
• another option for the JS client would be to use https://github.com/swagger-api/swagger-js. but this is totally dynamic, i.e. it dynamically defines the client based on the swagger spec (loaded from a URL), instead of generating static JS code. that feels less obvious/explorable for new devs, esp for use in writing tests. having the API client code explicitly written seems like it'd make grokking the client/server interactions easier for developers.

[jmartin-sul]

answers to some of the above:

how do we spin up the server automatically for testing

see #21. docker-compose up in a cicrcle-ci build where the tests are run in a machine executor job. would like to move off the machine executor if possible, but not a high priority at the moment.

do we need to seed some known test data in our test trellis-ext-db instance?

probably. the tests will likely need to do some setup of expected data.

do we need to write any more client code (not for testing)? or does swagger-codegen provide us with a fully implemented client that we can use?

seems like hopefully "no" and "yes", respectively.

if/when the swagger spec changes, what's a sane strategy for regenerating the client code and updating the tests as needed?

still no good answer for this one.