Skip to main content

Testing

@codespar/sdk/testing: fakeSession, a Session your tests can drive without network, keys or a tenant.

1 min read
View MarkdownEdit on GitHub
@codespar/sdkv0.16.0

@codespar/sdk/testing is a separate entry point of the same package. It gives your test a Session that satisfies the same type the runtime returns, answers the tool calls you register, and never opens a socket.

import {  } from "@codespar/sdk/testing";

const  = ({
  : {
    : true,
    : { : "chg_0000", : "00020126…" },
    : null,
    : 0,
    : "codespar",
    : "codespar_charge",
  },
});

const  = await .("codespar_charge", { : 150 });

fakeSession

ReadfakeSession(responses?: Record<string, FakeSessionResponse>, options?: FakeSessionOptions): Session
ParameterTypeRequiredDescription
responsesRecord<string, ToolResult | (input) => ToolResult | Promise<ToolResult>>noOne entry per tool name. A function receives the arguments the code under test passed, so you can assert on them or vary the answer.
options.lenientbooleannoWhen true, a tool name you did not register resolves to { success: true, data: {} } instead of throwing.

A function response is the useful half: it is where you check that the code under test sent the amount, the currency and the idempotency key you expect.

const : <<string, unknown>> = [];

const  = ({
  : () => {
    .();
    return {
      : true,
      : { : "chg_0001" },
      : null,
      : 0,
      : "codespar",
      : "codespar_charge",
    };
  },
});

await .("codespar_charge", { : 150, : "BRL" });
[0].; // "BRL"

A ToolResult is the whole envelope. success and data are not enough: the type also requires error, duration, server and tool, and tool_call_id and called_at are optional. The examples above carry the full shape, which is what the runtime returns and what your assertions will read.

A fake is not the mocks engine. fakeSession answers in your process and proves how your code reacts to a result. It does not exercise policy, approval, routing or the receipt chain. For a run that goes through the real runtime with deterministic providers, use test mode with a test key: the two answer different questions, and a green fake says nothing about a policy that would have denied the payment.

Strict by default

Without lenient, calling a tool you did not register throws. That default is deliberate: a test that silently passes on a tool nobody stubbed is a test that will keep passing after the code starts calling something else.

Testing | CodeSpar