Skip to content
Bynk

Run your tests

Goal: run a project’s test and integration blocks, read pass/fail, and — in your editor — click straight from a failing assertion to the line that failed.

Once you’ve written some tests, run them with bynkc test:

Terminal window
bynkc test            # from the project root

bynkc test compiles the project (every generated tests/*.test.ts module included), then runs the aggregated runner under Node — type-checking as it goes, so a type error stops you with the usual diagnostics. It exits non-zero if any case fails. You need node and tsc (or tsx) on your PATH; check with bynk doctor --only test.

commerce.money:
  ✓ accepts positive
  ✗ deliberate failure
    assertion failed at tests/commerce/money.test.bynk:8:12


1 passed, 1 failed.

A failed assert reports the path:line:col of the assertion that failed, for both unit and integration tests.

Machine-readable results: --format json

Section titled “Machine-readable results: --format json”

For CI and tooling, --format json emits a single, stable JSON document instead of the human lines:

Terminal window
bynkc test --format json
{
  "passed": 10,
  "failed": 1,
  "suites": [
    {
      "name": "commerce.money",
      "kind": "unit",
      "cases": [
        {"name": "accepts positive", "outcome": "pass"},
        {"name": "deliberate failure", "outcome": "fail",
         "message": "assertion failed at tests/commerce/money.test.bynk:8:12",
         "location": {"path": "tests/commerce/money.test.bynk", "line": 8, "col": 12}}
      ]
    }
  ]
}

Each suite carries a kind ("unit" or "integration") and a clean name; a failing case carries a message and a structured location for click-through. The exit code is unchanged — 0 only if the project compiled and every case passed.

There are three shapes a consumer should handle, distinguished by error:

  • a normal run — suites present, no error (it may still have failed > 0);
  • a compile failure — no suites; error.kind is "compile" and error.diagnostics carries the path:line:col: severity[category]: message lines (the same shape the editor’s problem-matcher reads);
  • a crashed run — the suites observed before the crash, plus error.kind "runtime" with the captured stderr.

The exit code always follows the runner’s own process status, so a crash is never reported as success.

In the editor: the Test Explorer

Section titled “In the editor: the Test Explorer”

The VS Code extension consumes that JSON surface directly. Open the Testing view (the beaker icon): the tree populates by discovery — bynkc test --no-run --format json lists your suites and cases without running them, so each test links to its .bynk line before you run anything (use the Refresh control to re-discover after edits). Run from the tree, or invoke Bynk: Run Tests from the command palette; results then show inline, a failing assertion links to its .bynk line, and a compile failure lands in the Problems panel exactly as bynkc check does. The extension resolves bynkc the same way the check task does — the bynk.compilerPath setting, else bynkc on PATH.

Section titled “Related”