I don't think we need to test every edge case for the Web API as we did for the CLI. Since they use the same core modules, that seems like duplicated effort.
We should treat it as "just another interface" for coffer's core, and test it as such:
make sure all inputs (URI path, query params, headers, etc) are correctly parsed and processed
make sure all outputs (response body, headers, status codes, etc) are correct
Testing the output of error scenarios does involve testing a lot of edge cases, but perhaps not as many as we did in the CLI, I hope.
We want these tests to serve as documentation. So let's not derive a servant client, let's use a lower level abstraction. And let's not use coffer's core data types/encoders/decoders, let's use json literals (e.g. with aesonQQ)
Clarification and motivation
This issue is blocked by #104.
I don't think we need to test every edge case for the Web API as we did for the CLI. Since they use the same core modules, that seems like duplicated effort.
We should treat it as "just another interface" for coffer's core, and test it as such:
Testing the output of error scenarios does involve testing a lot of edge cases, but perhaps not as many as we did in the CLI, I hope.
We want these tests to serve as documentation. So let's not derive a servant client, let's use a lower level abstraction. And let's not use coffer's core data types/encoders/decoders, let's use json literals (e.g. with aesonQQ)
Acceptance criteria