Verify Your Deployment
Verify the artifact and origin users will receive. Source checks and mocked SDK tests cannot prove that the customer build, deployment lease, worker assets, Content Security Policy, and production integrations work together in a real browser.
Test the release as one system
Run two complementary checks when your release process supports them:
- Deployed acceptance: exercise the candidate artifact against the production integrations and test accounts it will use after promotion.
- Deterministic browser test: exercise the same public SDK and adapter contracts against controlled test services or fixtures so loading, empty, rejection, reconnect, and cleanup outcomes are repeatable.
Do not mock createTradeScriptSdk, the mounted widget, or its public APIs. A
controlled boundary may replace an external market-data, broker, or storage
service, but the browser must still run the real customer SDK artifact and the
same adapter contract used by your application.
Release matrix
| Lane | Required proof |
|---|---|
| Release identity | Deployed application version, SDK version, build fingerprint, origin, and worker configuration match the candidate record. |
| Authorization | A current matching lease starts the SDK; missing, expired, wrong-origin, and wrong-build leases fail before licensed surfaces start. |
| Mount and readiness | mounted.ready() and chart.dataReady() resolve, and the chart surface has a non-zero size. |
| Market data | History loads, realtime updates, symbol and interval changes complete, and provider errors reach the intended user state. |
| Enabled capabilities | Each shipped drawing, indicator, storage, trading, replay, alert, news, or standalone widget journey completes through its public contract. |
| Workers | mounted.api.getWorkerStatus() matches the release configuration and worker assets load without CSP or MIME errors. |
| Failure states | Loading, empty, denied, transient network, terminal rejection, and expired-lease outcomes are understandable and recover only when safe. |
| Cleanup | Navigation or explicit destruction removes chart DOM, subscriptions, listeners, and workers without affecting a later remount. |
Rows for capabilities your product does not ship are not required. Record them as not enabled, rather than fabricating a passing test.
1. Prove the baseline through public APIs
The baseline below uses your real application datafeed and the lease supplied
by your backend bootstrap:
import { createTradeScriptSdk } from '@tradescript/pro/sdk/core';
import type { MarketDataFeed } from '@tradescript/pro/sdk/core';
declare const deploymentLease: string;
declare const datafeed: MarketDataFeed;
const mount = document.querySelector<HTMLElement>('#chart');
if (!mount) throw new Error('chart mount is missing');
const sdk = await createTradeScriptSdk({ lease: deploymentLease });
const mounted = sdk.chart.mount({
mount,
symbol: 'AAPL',
interval: '5m',
datafeed,
});
const widget = await mounted.ready();
await widget.chart().dataReady();
if (mount.getBoundingClientRect().height === 0) {
throw new Error('chart mount has no rendered height');
}
if (widget.chart().getLoadedBars().length === 0) {
throw new Error('chart loaded no bars');
}
mounted.destroy();
The test runner should also confirm that the browser loaded the expected customer artifact and that no authorization, asset, CSP, or worker startup error occurred before readiness.
2. Exercise each enabled integration
Use the focused contract guide for setup and assertions; keep the release result in this single matrix.
| Integration | Minimum release assertion |
|---|---|
| Datafeed | Change symbol and interval, receive one valid historical result, observe a realtime update, and confirm unsubscribe on teardown. |
| Trading | Connect a test account, read authoritative state, submit an allowed test mutation, observe the broker acknowledgement and state update, and prove a rejection path. |
| Storage | Save a uniquely named test object, load the same revision, update or delete it, and prove permission or conflict handling where supported. |
| Drawings and indicators | Create one enabled item, read it back through the public API, and remove it. |
| Replay, alerts, news, and widgets | Complete the smallest user-visible journey and its unavailable or denied state. |
See Test a broker integration for the trading fixture and mutation rules, Storage for persistence contracts, and Datafeeds for market-data terminal outcomes.
3. Prove failure behavior
At minimum, verify:
- the application keeps permanent credentials out of browser traffic and logs;
- an authorization failure does not start a licensed surface;
- a datafeed failure does not masquerade as an empty market;
- a storage failure preserves the current in-memory work;
- a broker rejection preserves the order draft and is never blindly retried;
- a recoverable network failure uses bounded retry; and
- a terminal failure produces a stable SDK code and useful redacted evidence.
Use Monitoring and error handling for retry and user-response rules.
4. Prove cleanup and remount
Record subscription, listener, and worker counts before mount, after readiness,
and after mounted.destroy(). They must return to the pre-mount baseline. Then
mount the same route again and confirm one fresh instance starts.
This catches route transitions that leave realtime subscriptions, storage listeners, broker connections, or worker tasks attached to a destroyed chart.
Release evidence
Keep one compact result with:
- deployed URL and timestamp;
- application version, SDK version, and customer build fingerprint;
- browser, operating system, and viewport;
- pass, fail, or not-enabled status for every matrix row;
- the first public error or failed assertion;
- redacted adapter call counts or request identifiers; and
- a screenshot only when it helps explain the visible result.
Do not attach permanent credentials, complete leases, broker secrets, complete orders, or unbounded market-data payloads.
Next steps
- Monitoring and error handling — classify and recover from production failures.
- Troubleshooting — reduce a failed release row to its owning boundary.
- Upgrades and rollback — promote the verified release while preserving a matched rollback unit.