Chapter 34 — Web3, blockchain and cryptoasset security: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 Integration points"]
N2["34.2 End-to-end testing"]
N3["34.3 Managing integration risk"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 Integration points"]
N2["34.2 End-to-end testing"]
N3["34.3 Managing integration risk"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 Integration points]
|
v
[34.2 End-to-end testing]
|
v
[34.3 Managing integration risk]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) integrate contracts with gateway, app and utility; (2) test end to end; (3) manage integration risk.
34.1 Integration points
The contracts must work with the gateway that submits minting batches, the member app that shows balances and initiates transfers, the database that produces statements, and the utility's billing system that receives redemption reports. Jonas lists each integration point with its interface agreement and owner. Integration is where earlier assumptions meet reality: the utility's system, for example, expects redemption reports in a fixed file format at a fixed time each night, which the design had not specified precisely. Each owner confirms their entry.
34.2 End-to-end testing
Jonas builds an end-to-end test on the test network: simulated meters produce signed readings, the gateway batches them, the minting contract issues credits, members transfer and redeem through the app, the database updates statements and a redemption file is produced for the utility. Each step is checked against expected outcomes, including invariants and reconciliation. The first run fails because the app shows balances before transactions are final, confusing users; he changes it to show pending and confirmed amounts separately. The test is then rerun.
34.3 Managing integration risk
Integration changes can break things far from where they are made. Jonas introduces a rule that any change to an interface requires updating the agreement, running the end-to-end test and notifying the other owner. He also schedules integration tests nightly on the test network. When the utility changes its file format with a week's notice, the agreement process catches it and the change is made before the deadline. Integration risk is managed through communication as much as through code. Records are kept.
Worked example
Five integration points are documented; the end-to-end test reveals a pending-balance display problem, and an interface change rule catches the utility's format change in time.
Synthetic case. Systems, tests and changes are synthetic.
Errors and limits
Testing contracts alone without end-to-end tests misses failures at integration points.
Exercises
- EX100 — Utility expectation. What did the utility system expect? Rubric: 3 = fixed file format at a fixed nightly time;; 2 = file format;; 1 = API calls;; 0 = none.
- EX101 — First failure. What did the first end-to-end run reveal? Rubric: 3 = app showed balances before finality;; 2 = pending balances;; 1 = vague;; 0 = none.
- EX102 — Interface rule. What does an interface change require? Rubric: 3 = update agreement, rerun end-to-end test, notify owner;; 2 = three steps;; 1 = vague;; 0 = none.
Synthesis
Documented integration points, end-to-end tests and interface change rules manage integration risk.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →