Running Tests

Glubean tests are designed to be run right where you write them, without ever leaving your editor or switching to a terminal.

Run from the gutter

Every test() call automatically gets a ▶ play button in the gutter next to the line number. Click it to run that single test instantly.

When the test finishes, a ✓ or ✗ icon appears in the gutter, and the Trace Viewer opens side-by-side.

Run the whole file

In the top-right corner of the editor (the title bar), there is a ▶ button when you have a *.test.ts file open. Clicking this will run all the tests in the active file sequentially.

Test Explorer

Glubean integrates deeply with VS Code’s native Test Explorer sidebar.

Your tests are organised into two main groups (based on the folder structure):

Explore — quick, uncommitted API exploration (explore/)
Tests — permanent, CI-ready tests (tests/)

From the Test Explorer, you can:

Run an entire folder or file
See the pass/fail status of your last run
Filter tests by name or failure state

Multi-step tests

If you use the builder API (test("id").step(...)), the Test Explorer will display each step as a child node in a tree. You can see exactly which step failed:


▼ auth-flow
  ✓ login          (142ms)
  ✓ get profile    (89ms)
  ✗ update name    AssertionError: expected 200, got 422

Re-run last test

Instead of reaching for the mouse, you can re-execute the most recently run test (or group of tests) by pressing:

Mac: Cmd + Shift + R
Windows/Linux: Ctrl + Shift + R

Data-driven tests (`test.each`)

For traditional data-driven testing where you want to execute a test against every row of data, use test.each. The Test Explorer will detect this and show each row as an expandable child node:


export const statusCodes = test.each([
  { id: 1,   expected: 200 },
  { id: 999, expected: 404 },
])("get-item-$id", async (ctx, { id, expected }) => {
  const res = await ctx.http.get(`/items/${id}`);
  ctx.expect(res.status).toBe(expected);
});

You can click the ▶ play button on individual rows in the Test Explorer to re-run specific cases.

Example-driven tests (`test.pick`)

If you use test.pick to provide a dictionary of named examples, the extension provides a CodeLens button directly above the code for each example:


export const createUser = test.pick({
  normal:      { name: "Alice", age: 25 },
  "edge-case": { name: "",      age: -1 },
  admin:       { name: "Admin", role: "admin" },
})("create-user-$_pick", async (ctx, example) => {
  // ...
});

You’ll see clickable text like ▶ normal | ▶ edge-case | ▶ admin floating above the function. Clicking one runs that specific example deterministically. If you just click the regular gutter play button without selecting an example, it picks one at random.

Loading examples from external files

You can also load examples from JSON or YAML files — keeping test code focused on logic while QA or product teams contribute test cases without touching TypeScript:


import examples from "./data/create-user.json" with { type: "json" };
 
export const createUser = test.pick(examples)(
  "create-user-$_pick",
  async (ctx, example) => {
    await ctx.http.post("/api/users", { json: example });
  },
);

CLI override

From the command line, you can run a specific example deterministically:


glubean run file.ts --pick admin

Tasks Panel (For QA & CI)

While developers use the Editor gutter or Test Explorer to run individual tests, QA engineers often want named, pre-configured run presets they can trigger with a single click.

The Glubean Tasks Panel surfaces glubean run tasks defined in your deno.json file as a dedicated Activity Bar view.

Setting up tasks

Define your test suites in deno.json under the tasks section:


{
  "tasks": {
    "test": "glubean run",
    "test:staging": "glubean run --env-file .env.staging",
    "test:smoke": "glubean run --tag smoke",
    "test:regression": "glubean run --tag regression",
    "test:ci": "glubean run ./tests --result-json .glubean/last-run.json --reporter junit:test-results.xml"
  }
}

Using the panel

Zero CLI Knowledge Required: Click the ▶ button next to any task in the panel (e.g., test:staging).
Single Source of Truth: CI and the IDE panel run exactly the same command defined in deno.json.
Results, Not Noise: The panel automatically parses the structured output from the CLI and shows clear ✓/✗ icons, timestamps, and pass/fail counts.
Auto-open Results: When a run completes with failures, the structured result JSON viewer opens automatically.