Test the guarantee and its failure case
Taskboard's code can look complete while its important guarantees fail. A tenant filter might be missing, a duplicate webhook might schedule two jobs, or a task response might be cached before authorization. Tests need to challenge those concrete mistakes.
The reference verification uses real Postgres and HTTP connections. SQL constraints, transactions, cookies, and middleware ordering operate together. A mock database that always returns the expected row cannot establish those behaviors.
Assert an observable outcome
For idempotency, send two requests with one key and verify one task row and one task ID. For tenant isolation, use a valid session from another workspace and verify that protected data never appears. For optimistic concurrency, submit competing versions and verify that only the allowed update commits.
Send a correctly signed event.
Send the same event again.
Observe one inbox identity and one scheduling obligation.
Send the same bytes with an invalid signature.
Observe rejection and no trusted inbox insert.
Checking only a success status would miss the duplicate row. Checking only that the handler function ran would miss whether the database transaction committed.
External boundaries need precise claims
A local SMTP server can prove that the worker submits a real message with the expected link. It cannot prove that a production recipient's inbox accepts it. A Stripe provider double can prove Taskboard's canonical-state translation and retries. It cannot prove the configured live account accepts real payment methods.
Socket tests connect authenticated clients, subscribe to projects, and observe a task-change event. The negative case checks that a different tenant receives nothing. Revocation tests check the connection after membership changes rather than only at initial handshake.
Worker tests can force a failure and inspect retry timestamps, attempt counts, and fenced completion. Process-crash testing, restore drills, and sustained load tests are additional evidence, not implied by a passing integration suite.
The verification report records which checks actually ran and any environmental limitations. Treat that report as the current evidence. The lesson explains the purpose of the checks without promising that every possible failure is covered.
Read testable boundaries in Read api/src/app.ts, Read api/src/jobs.ts, and Read api/src/billing.ts.
Test the behavior that would break a guarantee. A passing local suite has a defined scope and does not replace provider, deployment, or recovery verification.
Does a successful TypeScript build prove tenant isolation?
No. A well-typed query can still select another workspace's data. Isolation needs scoped operations, database constraints, and tests that attempt unauthorized access.