Merge #3862
3862: Make API error expectations compiler-checkable. r=jonathanknowles a=jonathanknowles
Follow-on from https://github.com/input-output-hk/cardano-wallet/pull/3824 ([ADP-2269](https://input-output.atlassian.net/browse/ADP-2269)).
## Summary
This PR replaces `expectErrorCode`, which creates expectations based on string comparisons, with `expectErrorInfo`, which creates expectations based on `ApiErrorInfo` objects.
This has two advantages:
- expectation expressions can be checked statically by the compiler.
- it's possible to express richer expectations based on internal fields of errors (not all errors are just simple values -- some have nested records), using combinators provided by `hspec`.
## Context
In our test suite we test at least two kinds of mapping:
- The mapping between API types and their serialised JSON representations: for all API types, the JSON encoding should be consistent with the OpenAPI specification, and the round trip property `(decode . encode == id)` should hold for all values.
- The mapping from (API call, inputs, state) to API response values: i.e, that API calls return the responses we expect, given appropriate inputs and the current (implicit) wallet state.
Up until now, the approach we've used in `cardano-wallet` is to separate the above two concerns into **different test suites**, i.e., to:
- test expectations about our JSON serialisation logic in specialised tests for just that purpose (JSON golden round trip tests and the test suite for the OpenAPI spec).
- within other test suites (such as the integration test suite), **assume** the correctness of our JSON serialisation logic, and express expectations in terms of ordinary (decoded) Haskell values.
API errors have, up until now, been a sort of exception to this separation of concerns, because until recently we didn't have a good way to create structured errors.
But since merging #3557, which provides support for structured errors and the accompanying [decodeErrorInfo](https://github.com/input-output-hk/cardano-wallet/blob/504774f0f08f4ec74fa91106bc004d8e7b97f875/lib/wallet/integration/src/Test/Integration/Framework/DSL.hs#L559) function, we've gradually been converting expectations about API errors to use the same style as we use for ordinary values returned by the API, which is to express expectations in terms of ordinary Haskell expressions, and to avoid writing expectations in terms of hard-coded strings.
For example, for ordinary (non-error) API responses, we typically write expectations like this:
https://github.com/input-output-hk/cardano-wallet/blob/7af6d54d21443146320eab04452eefb75b3d553e/lib/wallet/integration/src/Test/Integration/Scenario/API/Shelley/Transactions.hs#L297-L299
Co-authored-by: Jonathan Knowles <[email protected]>