You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<title>httpsuite — run JetBrains .http tests in CI, without the JVM</title>
7
-
<metaname="description" content="httpsuite runs the .http files you author in GoLand — pre-request scripts, response handlers, client.test assertions — as CI tests. A single static binary, no JDK, no CGO. Verified conformant against JetBrains' own ijhttp.">
6
+
<title>httpsuite — run .http API tests in CI, without the JVM</title>
7
+
<metaname="description" content="httpsuite runs the .http files you author in GoLand — pre-request scripts, response handlers, client.test assertions — as CI tests, with no JDK to install and no JVM to babysit. Verified conformant against JetBrains' own ijhttp.">
<metaproperty="og:description" content="Run JetBrains .http tests in CI, without the JVM. A single static binary, verified conformant against ijhttp.">
17
+
<metaproperty="og:description" content="Run .http API tests in CI, without the JVM. JetBrains HTTP Client compatible, verified conformant against ijhttp.">
@@ -434,14 +433,15 @@ <h1>JetBrains .http tests,<br>without the JVM.</h1>
434
433
435
434
<sectionclass="problem">
436
435
<divclass="container">
437
-
<spanclass="eyebrow">The problem</span>
438
-
<h2>API tests shouldn't drag a JVM into CI.</h2>
436
+
<spanclass="eyebrow">The case for .http</span>
437
+
<h2>API tests belong in your repo.</h2>
439
438
<pclass="prose">
440
-
The JetBrains HTTP Client is a great way to author and debug API requests — but running
441
-
those same <code>.http</code> files in CI means shipping <code>ijhttp</code> and a
442
-
<strong>JDK 25</strong> into every pipeline and container image. httpsuite runs the
443
-
identical files as a single ~14 MB static binary: the same scripts, the same
444
-
assertions, none of the runtime.
439
+
The requests you use to build and debug an API are worth keeping — but too often they
440
+
live in a GUI or a cloud workspace, drifting out of sync with the code they test.
441
+
<code>.http</code> files put them back where they belong: <strong>plain text, versioned
442
+
in git, reviewed in pull requests.</strong> httpsuite runs those same files in CI — the
443
+
identical scripts and assertions you ran in your IDE — with nothing to install: no JDK,
444
+
no Node, no runtime to provision, patch, and wait on.
445
445
</p>
446
446
447
447
<divclass="problem-grid">
@@ -451,7 +451,7 @@ <h2>API tests shouldn't drag a JVM into CI.</h2>
451
451
</div>
452
452
<divclass="problem-card">
453
453
<divclass="label">What it doesn't need</div>
454
-
<p>No JVM, no CGO, no daemon. A single static binary that runs on macOS, Windows, and any Linux — Alpine/musl, distroless, and <code>FROM scratch</code>containers included.</p>
454
+
<p>No JVM to provision, no runtime to keep patched, no daemon. It runs wherever your CI already does — macOS, Windows, and any Linux, down to Alpine/musl, distroless, and <code>FROM scratch</code>images.</p>
455
455
</div>
456
456
</div>
457
457
</div>
@@ -468,8 +468,8 @@ <h2>Everything the runner needs. Nothing it doesn't.</h2>
<p>Pure Go, no CGO, no JVM. ~14 MB, statically linked, cross-compiles to macOS, Windows, and every Linux arch. Drops into a distroless or scratch image unchanged.</p>
471
+
<h3>No JVM to babysit</h3>
472
+
<p>Nothing to install, provision, or keep patched. Where <code>ijhttp</code> needs a JDK 25 in every image, httpsuite is one small binary that drops into distroless or <code>scratch</code> unchanged.</p>
<p>An <code>httpsuite.yaml</code> groups files, runs them in parallel or serial with per-group timeouts, and layers <code>{{variables}}</code>. Or just point it at a directory.</p>
504
+
<p>An <code>httpsuite.yaml</code> groups files (parallel or serial, per-group timeouts), runs data-driven rows from inline tables, JSON or CSV, retries a request until it passes, and shares one logged-in session across a group's <code>setup:</code> and files. Or just point it at a directory.</p>
505
505
</div>
506
506
507
507
<divclass="feature">
@@ -512,6 +512,30 @@ <h3>CI-native output</h3>
512
512
<p>Coloured and aligned on a terminal, plain and diffable with no TTY, and JUnit XML via <code>--report</code> for your CI dashboard. Exit 0 pass, 1 fail, 2 setup error.</p>
<p>Reads the same <code>http-client.env.json</code> and <code>.private.env.json</code> files GoLand uses — <code>$shared</code> and private overrides included — with <code>--env prod</code>. No re-keying config for CI.</p>
<p>Dynamic <code>{{$uuid}}</code>/<code>{{$timestamp}}</code>, eager and lazy vars, a shared cookie jar, and in-place chaining like <code>{{login.response.body.$.token}}</code> — carry auth and IDs across requests without a line of script.</p>
537
+
</div>
538
+
515
539
</div>
516
540
</div>
517
541
</section>
@@ -618,14 +642,14 @@ <h2>Same file in the IDE and the pipeline.</h2>
Copy file name to clipboardExpand all lines: llms.txt
+7-1Lines changed: 7 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,15 @@
1
1
# httpsuite
2
2
3
-
> Runs JetBrains HTTP Client `.http` files as API tests in CI. Executes their pre-request and response-handler JavaScript, `client.test` assertions, and declarative `# @expect` checks — as a single static binary with no JVM and no CGO.
3
+
> Runs the `.http` files you author in the JetBrains HTTP Client (or VS Code REST Client) as API tests in CI. Executes their pre-request and response-handler JavaScript, `client.test` assertions, and declarative `# @expect` checks — as a single static binary with no JVM and no CGO.
4
4
5
5
httpsuite is a test runner for the `.http` files developers author in the JetBrains HTTP Client (GoLand, IntelliJ) or the VS Code REST Client. It runs the requests, executes the associated JavaScript — pre-request scripts (`< {% %}`) and response handlers (`> {% %}`) including `client.test`/`client.assert`, `client.global` cross-request state, the response DOM for XML, `crypto`, `jwt`, and `jsonPath` — and evaluates declarative `# @expect` assertions on status, headers, JSON body, types, dates, and duration. Output is coloured on a terminal, plain and diffable in CI, and available as JUnit XML via `--report`.
6
6
7
+
Positioning: httpsuite is part of the shift toward git-native, plain-text API testing — a developer-focused alternative to GUI- and cloud-based API clients such as Postman for the author-and-test loop. Because `.http` files are plain text, they live in the repository beside the code they test, diff in pull requests, and need no account or cloud sync. The same file a developer authors and debugs in their IDE runs unchanged in CI, so local and pipeline results agree by construction. httpsuite deliberately does not try to replace the collaboration, mocking, monitoring, or documentation features of a full API platform; it focuses on running the `.http` files you already have, in CI, with no runtime to install (no JVM, no Node). Its closest peers are other `.http` runners (JetBrains' `ijhttp`, which needs a JDK; httpyac, which needs Node) and other git-native API-testing tools that use their own formats (Bruno's `.bru`, Hurl); httpsuite's niche is being a zero-runtime CI runner for the portable `.http` format itself.
8
+
9
+
It parses the full portable `.http` syntax: request names (`###`/`# @name`), multi-line URLs, folded and spread headers, bodies from files (`< ./body.json`), form bodies, block comments, a per-session cookie jar, dynamic variables (`{{$uuid}}`, `{{$timestamp}}`, …), eager/lazy variables, in-place response chaining (`{{login.response.body.$.token}}`), and JetBrains environment files (`http-client.env.json`, including `$shared` and private overrides). httpsuite is a superset of the stock `ijhttp` CLI, additionally handling block comments, folded and spread headers, in-place response references, and lazy variables.
10
+
11
+
Beyond single files, an `httpsuite.yaml` suite groups `.http` files to run in parallel or serial with per-group timeouts and layered `{{variables}}`; it adds data-driven runs (each inline, JSON, or CSV row runs the group's files with the row's values as variables), a retry/until primitive (re-run a named request until its own assertions pass), and a shared session where `setup:` files (e.g. login) share one cookie jar, `client.global`, and response store with the group's files. This orchestration lives in the YAML, so the `.http` files stay portable and still run unchanged in the IDE.
12
+
7
13
The JavaScript is executed by the pure-Go goja engine (ECMAScript 2015+), so httpsuite is a single statically linked binary — no JDK, no CGO — that runs on macOS, Windows, and any Linux distribution including Alpine/musl, distroless, and `FROM scratch` containers. This is the key difference from JetBrains' own `ijhttp` CLI, which requires a JDK 25.
8
14
9
15
Compatibility with the JetBrains HTTP Client is verified empirically: a conformance harness runs the same `.http` files through both httpsuite and `ijhttp` and diffs their JUnit reports test-by-test. On the shared scripting API — `client`, `response`, `request`, the DOM, and `jsonPath` — the two tools agree. `crypto` and `jwt` are httpsuite extensions not present in stock `ijhttp`.
<h1>JetBrains .http tests,<br>without the JVM.</h1>
82
-
<pclass="lead">Run the <b>.http</b> files you author in GoLand as CI tests — one static binary, no JDK. <b>Verified conformant</b>against JetBrains' own ijhttp.</p>
80
+
<h1>Your .http tests,<br>without the JVM.</h1>
81
+
<pclass="lead">Run the <b>.http</b> files you author in GoLand as CI tests — no JDK, no JVM. <b>JetBrains HTTP Client compatible</b>, verified against its own ijhttp.</p>
0 commit comments