E2E tests

[ALiberalVoluntarist]

Testing Example Wallet Server

Test the example wallet server against the following middleware implementations:

py-middleware

go-middleware

express-middleware

Ensure the wallet server can successfully execute payments and broadcast transactions to the mainnet.

Verify compatibility of the Wallet Toolbox examples implemented in TypeScript and Go, ensuring consistent behavior and output across both implementations.

[jo7ueb]

@ALiberalVoluntarist here's some finding in my survey for E2E test.
I appreciate for your comments.

JSON-RPC Testing Review

This document tracks how we understand the architecture, what has already been ported, how we plan to test JSON-RPC across languages, and which questions remain unsolved.

---

1. Current Understanding (BRC-100, WalletInterface, Storage, Swagger)

• WalletInterface (28 methods) is the BRC-100 contract implemented by the SDK (TypeScript Wallet.ts, Python wallet.py, Go wallet). Applications call these methods locally; there is no mandatory HTTP exposure.
• StorageProvider & StorageServer: Wallets depend on a StorageProvider to persist data. When storage lives remotely, a JSON-RPC StorageServer (TS StorageServer.ts, Go storage.Server, Python JsonRpcServer + HTTP wrapper) mirrors the same methods over HTTP so wallets can reach it through StorageClient.
• Middleware: Authrite/payment middleware sits on the StorageServer boundary (TS uses createAuthMiddleware/createPaymentMiddleware). Python needs equivalent behavior when wiring Django/FastAPI handlers around JsonRpcServer.
• Swagger (HTTP Wallet JSON) documents an optional scenario where WalletInterface itself is exposed over HTTP. It is a reference implementation, not a requirement.
• Terminology alignment: “Wallet layer” handles BRC-100 logic. “StorageServer” is supporting infrastructure. A future “WalletServer” would sit above Wallet + Storage layers if someone wants to serve WalletInterface via REST/JSON.

---

2. Current Implementation Status (TS → PY port + other languages)

• TypeScript: Mature implementation with StorageServer, StorageClient, Wallet, middleware hooks, and manual RPC tests (e.g., adminStats.man.test.ts). Swagger docs exist for HTTP Wallet JSON.
• Go: storage.Server and storage.NewClient provide full JSON-RPC integration, with comprehensive tests in pkg/storage/server_test.go.
• Python:
  • JsonRpcClient (22 StorageProvider methods) and base JsonRpcServer are implemented.
  • Wallet class covers all 28 BRC-100 methods (port from TS).
  • Examples include a Django server that wires JsonRpcServer into an HTTP endpoint, but parity middleware and automated RPC tests are still missing.
  • Future work: JsonRpcClient still lacks 6 StorageProvider methods (isStorageProvider, setServices, abortAction, createAction, processAction, internalizeAction). These need RPC wrappers plus StorageProvider hooks so wallets can execute these flows against a remote StorageServer.
• Cross-language parity: Go currently has the strongest JSON-RPC coverage; TS has manual coverage; Python has functionality but lacks systematic testing/middleware parity.

---

3. Testing Strategy Going Forward

Goals

• Validate JSON-RPC behavior loopback-style in each language (P→P, T→T, G→G).
• Add cross-language smoke tests (e.g., Python client against TS server).
• Ensure middleware-sensitive paths (auth/payment) are exercised once parity exists.

Planned Work

1. Python loopback tests
   • New tests/rpc/ package with thin HTTP harness + in-memory StorageProvider.
   • Start with isAvailable, then expand to findOrInsertUser, createAction, listOutputs.
   • Include unit tests that call JsonRpcServer.handle_json_rpc_request directly to check protocol validation.
2. TypeScript loopback parity
   • Spin up StorageServer with SQLite/in-memory provider and drive it via StorageClient (mirroring Go).
3. Cross-language matrix
   • Stage 1: Python & Go clients hitting TS StorageServer.
   • Stage 2: TS & Python clients hitting Go server.
   • Stage 3: TS & Go clients hitting Python server once middleware is ready.
   • Maintain a matrix showing which combinations run in CI vs. optional/manual.
4. CI/automation
   • Tests must avoid external dependencies (use local DB fixtures).
   • Shared helper fixtures (test wallets, HTTP harness utilities) should be reusable across suites.

---

4. Open Questions / Risks

1. Key material management
   • How to provision deterministic test wallets/keys across languages and handle them safely in CI.
2. Initial UTXO funding
   • Strategy for tests that need spendable inputs (fixtures, mock faucets, etc.).
3. Stateful method dependencies
   • How to seed prerequisites (e.g., run createAction before abortAction) in deterministic test fixtures.
4. Authentication compatibility
   • Ensure that auth headers/signatures produced by each SDK interoperate when hitting another language’s server.
5. Schema/environment parity
   • TS→PY schema compatibility exists, but we need routine checks so SQLite/MySQL differences do not reappear.
6. Cross-language orchestration
   • Document the CI playbook: startup order, shared ports, auth config, teardown rules for multi-runtime suites.
7. Performance/timeouts
   • Heavy RPC methods (e.g., processAction) need baseline expectations to avoid flaky cross-language tests.
8. Middleware parity
   • Define Python’s Authrite/payment middleware story (py-middleware) and when tests should exercise it vs. bypass it.
9. Wallet server responsibilities
   • JSON-RPC covers storage only; if we ever need WalletInterface over HTTP, what is the architecture/testing strategy? Need to catalog current capabilities per language.

These items must be clarified before claiming full JSON-RPC parity across Python, TypeScript, and Go.