The goal of this plan is to test the end-to-end functionality of our entire system.
The system consists of 4 parts:
- Trader App
- Ledger
- Orderbook
- Verifiers
These tests will mock the interactions between these 4 services, most specifically the communication between the Orderbook, Ledger, and Verifiers.
Each API contract will implement HTTP endpoints. Future specs may use other methods of transport (websockets, MQ, etc). Any changes in communication protocol should be recorded here.
Each Verifier will present a common public API:
- POST ->
<path>/verify - POST ->
<path>/verify/<entity>
The payload should have this schema:
{
target: Verifiable,
signature: String
}
Where a Verifiable is any quantity that can be signed with a public key, and
the signature is the string produced by the signing function.
** Verifiable definition: TBD **
Each of which will return a Vouch struct serialized into JSON:
{
details_hash: String,
verifier_type: Int,
signature: String,
public_key: String,
vouch: Boolean
}
Some Verifiers may have the mandate to perform functions outside of
verification. The Ledger is one Verifier that fits this description. Verifiers
that have other responsibilities may implement endpoints under the action/
scope:
scope "<path>/action", LedgerWeb do
post("/update_balance, BalanceController, :update_balance)
...
end
Some verifiers will keep state. Thorough tests will query verifiers throughout the verification workflow to ensure that test is being stored and sent properly.
Any verifier that keeps private state should implement the following endpoint:
- GET ->
<path>/state
which will be cordoned off for the test environment with some kind of configuration value:
scope <path>, LedgerWeb do
if @include_black_listed_routes do
post("/state", EntriesController, :get_state)
end
end
Part of maintaining a secure, distributed, multi-service system is being able to reliably reproduce a scaled down version for testing. We can spin up and network docker containers for each service with a single compose file.
Some services will need to maintain databases. These, like the Ledger, can expose ports via the compose file only during tests.
The system tests will live at the root of the project in a test/ folder. A
compose file in this directory will start containers for each of the services,
ideally using a Dockerfile made specifically for testing.
Unfortunately, docker-compose doesn't have startup hooks (yet). So we'll have to
spin up all the containers with docker-compose up, and in a second terminal
window run the testing command (mix test etc).
If we want to automate these tests to run on CI, a bash script that unites these two commands might be the solution.