Albert

A VS Code extension for API testing, built around plain-JSON file formats that live in your repo next to the code they test — no proprietary collection format, no separate server, no account.

File types

There is no collection file. A "collection" is just a folder of .abrq / .abenv files — VS Code's own Explorer is the browser. Every file type is plain JSON, so they diff cleanly in git and stay readable even outside the extension (open any of them as text and you still get JSON Schema autocomplete/validation from VS Code's built-in JSON language service, via the editor-title Open File as Text button).

Getting started

1. Right-click a folder → Albert: New Environment Config, add variables (e.g. baseUrl).
2. Command Palette → Albert: Select Active Environment and pick that file. The status bar shows Env: <name> and is clickable to switch.
3. Right-click a folder → Albert: New API Request File. This opens a custom editor with three tab groups:
   • Compose Request — Headers, Query, Body (Monaco editor, JSON Prettify + format-on-save), Auth, and Preview (the request with {{variables}} resolved, without sending — with a Copy as cURL button).
   • Validate Response — Expect (no-code assertions on status/header/body), Schema (AJV JSON Schema against the response body), Scripts (pre-request/post-response JS with request/response/environment globals + Jest-style expect()), Sample (a pasted sample response so you can write and run tests with Run against sample before a live endpoint exists), Response (the live result: Body with Copy body, Headers, Tests, Request sub-tabs), and Allure (report metadata — see below).
   • History — every live send this session (request + response + test results), expandable, not persisted to disk. A Save result as Markdown action turns the latest result into a shareable .md snippet. Tabs with a validation problem (bad JSON, invalid schema, broken regex) show a ⚠ warning badge so you don't have to open every tab to find what's wrong.
4. Click Send. While a request is in flight the button becomes Cancel (flows and sims have the same Stop/Cancel control while running).

Flows

Right-click a folder → Albert: New API Flow to create a .abf. Add steps, pick a .abrq request for each, optionally toggle validate (runs that request's Expect assertions + schema as k6 checks) and add captures (pull a value from a step's response body/header/status into a flow-scoped {{variable}} usable by later steps). Click ▶ Run flow to execute the whole flow once via k6 (1 VU / 1 iteration); per-step status, timing, validation checks, and a response-body preview stream into the results panel as the run progresses. Step result cards can expand to show request headers/auth/body and response headers/body, and surface that step's Allure metadata (epic/feature/story/suite/severity/owner/tags/description) as a badge with a tooltip.

Each run is added to a Run history list at the bottom of the flow editor (most recent first, kept per editor session, outlined as bordered cards consistent with the .abh viewer). Expand any entry to see that run's per-step detail. Click Save history… to write the runs to a *.abh file; opening that file uses a read-only history viewer that renders the same per-step results — handy for archiving a run or sharing it alongside the repo.

k6 is the execution engine for flows (and sims). On first run Albert downloads and caches a pinned k6 release into its global storage automatically — no manual install. To use your own k6 binary instead, set the albert.k6Path setting to its path.

Sims (load & stress testing)

Right-click a folder → Albert: New Load Simulation to create a .abl, then click + Add flow for each .abf you want to drive. Each flow entry is fully independent: set its own start at delay (seconds into the run before it kicks off, mapped to k6's scenario startTime), target TPS, ramp up, hold, and ramp down durations — setting ramp up/down to 0 gives a flat constant load for the hold duration. Duration fields accept 30s, 10m, 1h, or a compound 1h 12m 30s; a bare number is treated as seconds, and values display the same way (e.g. 1h 12m 30s). Each flow becomes its own k6 arrival-rate scenario with its own schedule and pattern, so a single sim can stagger flows to start at different times and drive them at independent throughputs and independent shapes/durations simultaneously. Click ▶ Run sim; results update live during the run and stay after it finishes, with a switcher between three views — all rendered locally, no external service required:

• XY chart — throughput (req/s), p95 latency, and error-rate plotted over time per flow, plus achieved-TPS and p95 bar charts.
• Sankey — load distribution as a flow diagram: total load → each flow (width ∝ request count) → Success / Error outcome, so you can see at a glance where traffic and failures concentrate.
• Table — per-flow summary (achieved vs. target TPS, request count, error %, p50/p95/p99, checks).

Before you run anything, the same view switcher also shows a Planned load (preview) panel computed from each flow's own profile + target TPS — the XY view plots the arrival-rate curve each flow will follow over time (ramp/hold/spike shape), the Sankey shows how the planned request volume splits across flows, and the Table lists planned requests per flow. The preview is derived from the same load model the k6 scenarios are generated from (src/model/loadProfile.ts), so what you preview is what runs.

New Relic export (optional): tick "Send results to New Relic", choose the region (US/EU), and set your Metric API key (the in-editor button, or Albert: Set New Relic API Key — stored in VS Code SecretStorage, never in the .abl file). After each run Albert POSTs per-flow metrics (achieved TPS, error rate, latency percentiles, request counts, check pass-rate) to New Relic's Metric API. Runs work fine without a key — the export is simply skipped.

Allure reporting

Albert can report flow runs to an Allure report server (it does not report individual requests sent via the Send button, and the CLI does not report to Allure). Turn it on in settings:

The Flow editor's header shows a live Allure: Enabled/Disabled status pill so you always know whether a run will be reported, without checking settings — it updates immediately if you flip the setting while the editor is open.

Each .abrq request has an Allure tab to set its report metadata: description, severity (blocker/critical/normal/minor/trivial), an epic/feature/story picker (pick a .abepic file, then a .abfeat it lists, then one of that feature's stories), suite, owner, and tags. When a flow runs, Albert aggregates each step's metadata, attaches that step's request/response as result attachments and its checks as nested steps, and POSTs the run to the Allure server's send-results endpoint — no extra setup beyond pointing the settings at a running server.