Crypto Trading Bot Unit Testing: A Developer Guide for Node.js and TypeScript

Backtesting evaluates how a strategy might have performed on historical data. It focuses on alpha and market fit. In contrast, unit testing evaluates code correctness. A strategy can be theoretically profitable but fail in execution because the code doesn't handle the response shape from the bybit-api correctly. Unit tests verify the mathematical accuracy of your indicators and signal generation logic. They ensure that when your strategy calculates a signal, the underlying code produces the correct parameters every time. While backtesting tells you if an idea is good, unit testing tells you if your implementation is reliable.

Testing in production is a high-risk engineering pattern that often results in lost capital. Live exchanges are non-deterministic; prices move, APIs lag, and connections drop. Unit tests provide a safety net that allows for rapid iteration and refactoring. When you update your risk engine, a comprehensive test suite confirms that you haven't broken existing logic in seconds. The engineering risk of deploying untested code is magnified in crypto. Without unit tests, you're forced to rely on slow manual tests on a testnet. Using a stable implementation layer like the Siebly.io SDKs for OKX or Binance allows you to focus on writing these tests. The typed request and response shapes in these libraries provide a clear blueprint for your mocks, ensuring your bot's state management remains sound even when market conditions shift.

TypeScript interfaces are the backbone of a testable architecture. By defining an interface for your exchange service, you can create multiple implementations: one that uses the real bybit-api and another specifically for your test suite. Constructor injection is the preferred method for trading bot components. It makes dependencies explicit and ensures that a class cannot be instantiated without its required services. This pattern allows you to swap a live Siebly SDK client with a mock client during testing without changing a single line of your execution logic.

Here is a minimal pattern using bybit-api and RestClientV5:

import { RestClientV5 } from "bybit-api";

interface OrderExecutor {
  submitMarketBuy(symbol: string, qty: string): Promise;
}

class BybitOrderExecutor implements OrderExecutor {
  constructor(private client: RestClientV5) {}

  async submitMarketBuy(symbol: string, qty: string): Promise {
const response = await this.client.submitOrder({
category: "spot",
symbol,
side: "Buy",
orderType: "Market",
qty,
});

if (response.retCode !== 0) {
throw new Error(response.retMsg);
}

return response.result.orderId;
  }
}

Your strategy class depends on OrderExecutor, not on RestClientV5 directly. In production you pass a real client. In tests you pass a mock.

A mock is a simulated object that mimics the behavior of a real API client. To create effective mocks, use the exact JSON shapes provided in official exchange documentation as your data source. This ensures your tests reflect real-world scenarios, including edge cases like partial fills or empty order books. You should also simulate API errors, such as authentication failures or 429 rate limit responses, to verify your bot's error handling logic.

Siebly SDKs expose rate limit state where the exchange provides it (for example, Binance's getRateLimitStates() and Bybit's optional parseAPIRateLimits header parsing), but they do not automatically throttle, queue, or retry requests when you hit a limit. Your unit tests should confirm that your own backoff or queuing logic reacts correctly when the exchange returns a 429. For more advanced implementations, you can explore engineering patterns that simplify state management in high-frequency environments.

A Vitest test against the executor above:

import { describe, it, expect, vi } from "vitest";
import { RestClientV5 } from "bybit-api";
import { BybitOrderExecutor } from "./BybitOrderExecutor";

describe("BybitOrderExecutor", () => {
  it("submits a market buy with the expected request shape", async () => {
const mockClient = {
submitOrder: vi.fn().mockResolvedValue({
retCode: 0,
retMsg: "OK",
result: { orderId: "abc-123" },
}),
} as unknown as RestClientV5;

const executor = new BybitOrderExecutor(mockClient);
const orderId = await executor.submitMarketBuy("BTCUSDT", "0.001");

expect(mockClient.submitOrder).toHaveBeenCalledWith({
category: "spot",
symbol: "BTCUSDT",
side: "Buy",
orderType: "Market",
qty: "0.001",
});
expect(orderId).toBe("abc-123");
  });

  it("surfaces rate limit errors from the exchange", async () => {
const mockClient = {
submitOrder: vi.fn().mockRejectedValue({
code: 429,
message: "Too many requests",
}),
} as unknown as RestClientV5;

const executor = new BybitOrderExecutor(mockClient);

await expect(
executor.submitMarketBuy("BTCUSDT", "0.001"),
).rejects.toMatchObject({
code: 429,
});
  });
});

Mocking WebSocket streams requires a different approach. Siebly WebsocketClient classes extend Node's EventEmitter, so you can simulate incoming market data or account updates by emitting the same event names your production handler listens for. By emitting specific events in your test environment, you can trigger your bot's response logic and verify its internal state changes. This is particularly useful for testing awaitable WebSocket commands, where your bot expects a specific confirmation after sending an order placement request.

import { EventEmitter } from "events";

class MockBybitWsClient extends EventEmitter {
  emitOrderUpdate(payload: { orderId: string; orderStatus: string }) {
this.emit("update", {
topic: "order",
data: [payload],
});
  }
}

Architecting a reliable system requires a pyramid-based testing strategy. At the base are unit tests: these are fast, frequent, and should cover every logic branch in your code, from signal math to risk calculations. The middle layer consists of integration tests that verify the connection to testnet environments using SDKs like binance or okx-api. These tests ensure your bot correctly handles the authenticated request/response shapes defined by the exchange. At the top is paper trading, which validates real-time behavior and WebSocket stream reliability without financial risk. This hierarchy ensures that by the time you reach the most expensive testing phase, your core logic is already proven.

Each testing method serves a specific purpose in the development lifecycle. Use unit tests to verify the mathematical accuracy of your indicators, the correctness of your signal generation logic, and the structural integrity of your order construction. This is where you test how your bot reacts to specific scenarios, such as a zero balance or a rejected order from the bybit-api. Backtesting is reserved for parameter optimization and ensuring the strategy remains relevant across different historical market conditions. Finally, use paper trading for latency checks and to verify that your WebSocket subscriptions remain stable over long durations. For developers looking to streamline this process, the siebly.io/ai framework provides optimized tools for building testable, event-driven architectures that move seamlessly between these environments.

From the Bybit SDK examples:

import { WebsocketAPIClient } from "bybit-api";

const wsClient = new WebsocketAPIClient({
  key: process.env.API_KEY,
  secret: process.env.API_SECRET,
  // testnet: true,
});

const response = await wsClient.submitNewOrder({
  category: "linear",
  symbol: "BTCUSDT",
  orderType: "Limit",
  qty: "0.001",
  side: "Buy",
  price: "50000",
});

console.log("submitNewOrder response:", response);

The same pattern exists on OKX and Binance via their respective WebsocketAPIClient classes. On Coinbase, use sendWSAPIRequest() on WebsocketClient for promise-based WebSocket API calls.

Using exported interfaces from the Siebly SDK documentation ensures your mocks stay in sync with real APIs. In a TypeScript environment, these types prevent silent failures. If an exchange changes a response field, your compiler will flag the mismatch in your test suite before the code ever reaches production. You can integrate these SDKs with popular testing frameworks like Vitest or Jest by simply providing the SDK interface as the type for your mock client. This reduces the boilerplate required to simulate complex exchange interactions.

Reliable bots must handle more than just market data; they must process private account streams and order state changes with high precision. You can verify this behavior by simulating incoming events in your test suite. It's also critical to test reconnection logic. By manually triggering disconnect events in a controlled environment, you can confirm that your bot attempts to re-establish the stream without losing track of its current orders.

For teams leveraging AI coding agents, the structured definitions found at siebly.io/ai allow these tools to generate unit tests automatically. The agents can parse the SDK typed request shapes to create a comprehensive set of test cases that cover both successful execution and common error scenarios. This speeds up the development cycle while maintaining a high standard of code quality. To get started with a testable architecture, browse the available Siebly SDKs for your preferred exchange.

Exchange sandboxes let you execute orders and manage account state with virtual funds. Bybit exposes a dedicated testnet (testnet: true). Binance supports both a separate testnet (testnet: true) and demo trading (demoTrading: true) with real market data but simulated balances. Pick the environment that matches what you are validating: protocol and signing correctness on testnet, or strategy behavior closer to production on Binance demo trading.

Since Siebly SDKs do not automatically throttle or retry on rate limits, this stage is also where you confirm your bot interprets 429 responses and applies the right backoff. You can find setup walkthroughs in the Bybit JavaScript tutorial and the Binance JavaScript tutorial. This phase should also confirm that your WebSocket reconnection logic functions correctly when the server terminates a session.

Bybit testnet REST client:

import { RestClientV5 } from "bybit-api";

const client = new RestClientV5({
  testnet: true,
  key: process.env.BYBIT_TESTNET_KEY,
  secret: process.env.BYBIT_TESTNET_SECRET,
});

const response = await client.submitOrder({
  category: "spot",
  symbol: "BTCUSDT",
  side: "Buy",
  orderType: "Market",
  qty: "1",
});

Binance testnet or demo trading:

import { MainClient } from "binance";

const client = new MainClient({
  api_key: process.env.BINANCE_API_KEY,
  api_secret: process.env.BINANCE_API_SECRET,
  // testnet: true,
  // demoTrading: true,
});

Transitioning to production requires strict safety boundaries to protect your capital from execution errors. Your deployment workflow must prioritize security and system stability through the following engineering patterns:

• Least-Privilege API Keys: Generate keys with the absolute minimum permissions required. Explicitly disable withdrawal permissions for all automation keys.
• Circuit Breakers: Implement logic that halts the bot if execution patterns deviate from expected parameters, such as excessive order rejection rates or unexpected balance shifts.
• Continuous Monitoring: Use paper trading as a parallel monitoring tool. By running a simulation alongside your live bot, you can identify edge cases missed by your unit tests without risking real assets.

Monitoring production logs is essential for catching non-deterministic errors that only appear under specific market conditions. By maintaining a clean, testable integration layer with Siebly.io SDKs, you ensure that your production code remains modular and easy to debug. This structured approach moves your system from a local prototype to a robust execution engine capable of operating reliably in professional workflows.

Vitest is a strong choice for modern Node.js and TypeScript projects because of native ESM support and fast watch mode. Jest is also widely used and is what the Siebly SDKs themselves run in CI. Either works well; pick the one that fits your project setup. The important part is that your tests stay isolated from live exchange calls.

Mocking WebSocket data streams is best achieved by using the Node.js EventEmitter class to simulate incoming events. Siebly WebsocketClient classes already extend EventEmitter, so your mock can emit the same update, open, or reconnect events your production code listens for. This lets you verify reactive logic in a deterministic environment without relying on exchange uptime.

Unit tests cannot verify the profitability of a strategy; they are designed to verify code correctness and mathematical accuracy. To evaluate performance against market conditions, you must use backtesting on historical data or paper trading on live data. Unit tests ensure your order sizing and signal generation logic function as intended before those simulations begin.

Specialized SDKs like bybit-api or okx-api provide exported TypeScript interfaces that define exact request and response shapes. Using these typed definitions is more efficient than raw fetch calls because it allows you to create robust mocks that stay in sync with the exchange API. This reduces the boilerplate code required to maintain your test suite and prevents silent failures.

You don't need an internet connection to run unit tests because they should be completely isolated from external APIs. By using dependency injection to swap live clients for local mocks, your test suite remains portable and execution speed is not limited by network latency. This isolation is a core requirement for a reliable CI/CD pipeline that runs in seconds.

Siebly SDKs may expose rate limit headers or state (for example, getRateLimitStates() on Binance or Bybit's parseAPIRateLimits option), but they do not automatically throttle or retry when you exceed a limit. Handle that in your bot's execution logic. In unit tests, have your mock client reject with a 429-shaped error so you can verify your backoff or queuing behavior without getting throttled during development.

Unit testing verifies individual functions or classes in isolation, while integration testing verifies the interaction between your bot and the exchange API. Unit tests use mocks to simulate responses, whereas integration tests use a sandbox environment such as the Bybit testnet or Binance testnet/demo trading to confirm that authentication and request signing work against real servers.

You should never include real API keys in your unit test files or repository. Unit tests should use dummy strings for credentials since they never make real network requests. For integration tests on a testnet, use environment variables and ensure that your keys have least-privilege permissions with withdrawal capabilities strictly disabled to maintain maximum security.