Debugging

Breakpoints in test code

Glubean tests run on Deno, which exposes a full V8 inspector. VS Code’s debugger connects to it automatically — so you get the same breakpoint experience you’d expect from any Node.js project.

To debug a test:

1. Set a breakpoint anywhere in your *.test.ts file — click the gutter to the left of a line number.
2. Right-click the ▶ button next to the test( call and choose Debug Test, or select it from the Test Explorer context menu.
3. Execution pauses at your breakpoint.

From there you can:

• Step through lines with F10 / F11
• Inspect variables in the Run and Debug sidebar
• Evaluate expressions in the Debug Console
• Hover over any variable in the editor to see its current value

Inspecting HTTP calls

The debugger is most useful when you want to understand what’s happening between steps. For example:

export const createAndFetch = test("create-and-fetch")
  .step("create", async (ctx) => {
    const res = await ctx.http.post("/api/users", { json: { name: "Alice" } });
    const body = await res.json();  // ← set a breakpoint here
    return { id: body.id };
  })
  .step("fetch", async (ctx, { id }) => {
    const res = await ctx.http.get(`/api/users/${id}`);
    ctx.expect(res.status).toBe(200);
  });

Pause after .post() and inspect res directly in the debug console — status code, headers, raw body — before the assertion runs.

Tips

Use ctx.log() for lightweight tracing — if you just want to understand the flow without stopping execution, ctx.log() writes structured output to the trace file and the terminal. No debugger needed.

ctx.log("User created", { id: body.id, status: res.status });

Step over await calls — use F10 to step over async calls and land on the next line after the promise resolves, rather than stepping into the runtime internals.

Debug Console expressions — while paused, type any expression in the Debug Console to evaluate it in the current scope:

> res.status
200
> JSON.stringify(body, null, 2)
'{\n  "id": 42,\n  "name": "Alice"\n}'