Add backend integration testing (API and other stuff)

[LukasKalbertodt]

One good way to automatically test Tobira is to run tobira serve, send HTTP requests to it and check if the response matches our expectations. This is particular useful for the API, but it also makes sense for some other routes. And sometimes, it's even useful to run a different subcommand and see if the binary behaves as expected, e.g. tobira --version should output the version and do nothing else.

I will call all of these kinds of tests "integration tests". We build the Tobira binary, run it and then somehow poke at it to make sure the behavior is correct.

Setting this up is not trivial: each Tobira process should have its own database and search index. Each potentially needs to be configured differently. And each one needs to listen on a different Unix socket. Note that many of these tests can run in parallel! I started this work and I think ended up with a solid foundation. Though it still is not done yet. See this branch or specifically 8406ee9d3b9fff29a0dcc1aa9042ef70b10c203f for my work. These tests are executed as part of cargo test. Each .rs file inside backend/tests is treated as separate test suite. You can also say cargo test --test api to only run one test suite.

As you can see, there are merely 3 tiny tests so far. I expect that many convenience functions need to be added still. Some things I already noticed:

• Always checking that the response status is_success() is duplication. It should check that by default (with an option to opt-out to check that some routes do indeed not respond with 2xx).
• Converting to serde_json::Value and then manually poking it is not great. That should be easier. For some cases, we can probably just do assert_eq!(value, json!({ "data": ... }));, i.e. use the serde_json::json! macro to just write down the whole object we expect. But this won't work in all situations as IDs of objects are random. So we need to come up with a good function or macro to very conveniently assert things about a returned JSON blob.
• Building a GraphQL request right now is tedious. This obviously need to improve drastically as well. Surely we can add a nice method on HttpClient so that one can just client.graphql(query, variables) or something like that. Or well, even better, in API tests we also don't want to repeatedly call that AND resp.json(). All API responses should be json. So yeah, making writing the actual tests as simple and boilerplate-free as possible!

---

Specific test ideas

Just collecting random ideas here, feel free to add to this list.

API tests

• [ ] ...

Other HTTP tests

• [ ] ...

Non tobira serve tests

• [ ] Making sure the configuration is correctly read and validated