How Monokulo is tested

Scanning blocks and the mempool, confirmations, reorgs, proof of work and the order statuses customers see.

• Repeated multi order forks faults and restarts preserve money
• Reorg collection of mined outputs crosses full queue pages without losing outputs
• Each transaction visits each tenant independently

Signed deliveries to the shop, retries and backoff, and the WooCommerce receiver checking them.

• Each webhook says how it is doing; the deliveries of one that needs you are open
• A delivery's details open as a dialog, with its attempts, request and last response
• A webhook with many deliveries pages through them in place, 20 at a time

The hosted payment page with and without JavaScript, the embed, and the point-of-sale screen on phones and tablets.

• The engine page follows the engine live, scrubs, replays and moves its window
• A POS session reads as one timeline, from opting in to the last event
• A POS session reads as one timeline, from opting in to the last event

Admin pages, stores, nodes, every setting and where its value comes from, and options-file handling.

• The site, the POS and the hosted payment page share one theme, light and dark
• Every tab, for the gallery
• The Monero nodes tab is marked while the only node of a network stores use is down

Encrypting view keys at rest, routing between custody backends, and SEV-SNP attestation.

• Sparse window histories match fresh scans without rebuilding kept keys
• Lookup ranges match fresh scans and do not poison the live window
• Concurrent wallet scans keep independent caches and matches

SQLite schema, single-writer guarantees, crash recovery and resuming after restarts.

• Killing the engine at random moments never loses a confirmed order or reuses an address
• Historic upgrades recover from process death
• Repeated saturation retains fifo fairness and cancellation

Fiat prices from each provider, currency handling and their settings.

• A policys answer never depends on which policy asked first
• Concurrent callers with different policies share one fetch and keep their own answers
• Haveno prices from its book and a one sided book hands over to the next

Rate limits, client challenges and the under-attack switch.

• Real challenge continues inside a cross-site checkout frame with and without JavaScript
• Real challenge offers a ten second no-JavaScript continuation
• Real challenge solves in JavaScript and continues to the checkout

Structured logs, the log viewer, trace context across engine, server and plugin.

• The search box, Syntax and Search share one height; Syntax opens the help as a dialog
• A line's properties load when it's first opened, and only then
• A search that does not parse says where

Connecting a store, taking payment, and mapping webhook statuses to WooCommerce orders.

• A genuinely forced order expired webhook is delivered and verified
• A full woocommerce checkout is created with the key opened and paid
• Create order against a real engine yields a working checkout redirect

The stagenet test wallet and fixtures the other suites stand on. Tested too.

• Background loops genuinely write a real expired order event
• A held lock names its holder and lets the caller choose
• One command runs and exits and existing wallets are never replaced

Shared types, HTTP plumbing and helpers.

• A store changes its wallet: the dropdown asks first, then the history shows both
• A save says so on the card and in a toast; a refused one keeps what was typed
• A change marks its card and shows the save bar, and Discard puts it back