Electrobun Kitchen Sink

The Kitchen Sink is Electrobun's integration test app. It contains automated and interactive tests for every Electrobun API, plus standalone playground windows for manual exploration.

Project Layout

kitchen/
├── scripts/
│   ├── generate-manifest.ts   # static parser → feature-manifest.json
│   └── validate-manifest.ts   # consistency checks
├── src/
│   ├── bun/index.ts           # Electrobun bun-side entrypoint
│   ├── generated/
│   │   ├── manifest-types.ts  # TypeScript types for the manifest
│   │   └── feature-manifest.json  # generated feature index
│   ├── test-framework/        # test executor & result types
│   ├── test-runner/           # test runner UI (views://test-runner/)
│   ├── test-harness/          # webview used by automated tests
│   ├── tests/
│   │   ├── index.ts           # aggregates all suites
│   │   ├── *.test.ts          # automated test suites
│   │   └── interactive/       # interactive test suites
│   └── playgrounds/           # standalone feature demo windows
└── electrobun.config.ts

Running the Kitchen Sink

cd kitchen && bun install

# Dev mode — opens test runner window
electrobun dev

# Watch mode — auto-rebuilds on file change
electrobun dev --watch

# Auto-run all automated tests and exit (CI / headless)
AUTO_RUN=1 electrobun dev

# Run a single test by name
AUTO_RUN_TEST_NAME="Window creation with URL" electrobun dev

Exit codes:

0

1

Feature Manifest

Generated at

kitchen/src/generated/feature-manifest.json

{
  "id": "window-creation-with-url",         // stable slug
  "title": "Window creation with URL",      // human-readable
  "category": "BrowserWindow",              // API grouping
  "description": "Test creating a window with a URL",
  "interactive": false,                     // true = requires human input
  "testFile": "src/tests/window.test.ts",   // source location
  "playgroundRoute": null,                  // e.g. "playgrounds/clipboard/index.html"
  "apiSurface": ["BrowserWindow"],          // Electrobun APIs exercised
  "uiSelectors": [],                        // CSS selectors used in playground
  "platformCaveats": []                     // e.g. ["requires CEF renderer"]
}

Regenerate / Validate

cd kitchen
npx tsx scripts/generate-manifest.ts   # parse defineTest() calls, write manifest
npx tsx scripts/validate-manifest.ts   # check all tests have manifest entries, no dups

Generator does static analysis only — no Electrobun runtime required.

Test Suites

Automated (run unattended)

Interactive (require human)

<electrobun-webview>

<wgpu-view>

Test Runner UI — CSS Selectors

Main window:

views://test-runner/index.html

Controls

#btn-run-all

runAllAutomated()

#btn-run-interactive

runInteractiveTests()

.run-btn[data-test-id]

runTest({ testId })

#test-search

#update-btn

applyUpdate()

#update-history-toggle

#update-history-clear

clearUpdateStatusHistory()

Status elements

#total-count

#passed-count

#failed-count

#pending-count

#test-list

#search-meta

Interactive modal

#interactive-modal

#modal-title

#modal-instructions

#btn-start

submitReady({ testId })

#btn-pass

submitVerification({ testId, action: 'pass' })

#btn-fail

submitVerification({ testId, action: 'fail' })

#btn-retest

submitVerification({ testId, action: 'retest' })

#notes-input

Bun↔UI RPC Contract

Requests (bun exposes to UI)

• getTests()

  → test list

• runTest({ testId })

  → run one test

• runAllAutomated()

  → run all automated

• runInteractiveTests()

  → start interactive sequence

• submitInteractiveResult({ testId, passed, notes })

  → submit result

• submitReady({ testId })

  → signal ready for interactive step

• submitVerification({ testId, action, notes })

  → pass/fail/retest

• applyUpdate()

  → apply downloaded update

• getUpdateStatusHistory()

  /

  clearUpdateStatusHistory()

• getTestRunnerPreferences()

  /

  setTestRunnerPreferences({ searchQuery })

Messages (bun sends to UI)

• testStarted

  — test execution began

• testCompleted

  — result with pass/fail/duration

• testLog

  — log line

• allCompleted

  — all tests done

• interactiveWaiting

  — waiting for user to click Start

• interactiveReady

  — user ready, perform the action

• interactiveVerify

  — show pass/fail/retest controls

• buildConfig

  — app metadata

• updateStatus

  /

  updateStatusEntry

  — updater state

Interactive Test Flow (Two-Step)

1. User clicks Open on an interactive test
2. Runner shows modal: instructions + #btn-start
3. User reads instructions, clicks Start → submitReady()
4. A secondary playground window opens (bun-side)
5. User performs the described action in that window
6. Modal shows: #btn-pass, #btn-fail, #btn-retest
7. User marks result → submitVerification()
8. Modal closes, result recorded

Consuming the Manifest (agent usage)

# Read the manifest
cat kitchen/src/generated/feature-manifest.json

# Filter: automated tests only
jq '[.[] | select(.interactive == false)]' feature-manifest.json

# Filter: tests for a specific API
jq '[.[] | select(.apiSurface | contains(["BrowserWindow"]))]' feature-manifest.json

# Map test to source file
jq '.[] | select(.id == "window-creation-with-url") | .testFile' feature-manifest.json

Playground Windows

Each interactive suite opens a dedicated playground window. Key ones:

views://playgrounds/file-dialog/

#openDialogBtn

#result

#history

views://playgrounds/application-menu/

views://playgrounds/context-menu/

views://playgrounds/webviewtag/

views://playgrounds/session/

views://playgrounds/window-events-*/

views://playgrounds/clipboard/

views://playgrounds/tray/

Platform Caveats in Tests

• Zoom: exact zoom level only verified on macOS; defaults to

  1.0

  on other platforms
• Minimize/unminimize: marked unreliable on some Linux window managers
• Session cookies: some tests commented out due to ARM Windows VM crashes
• Application menus: intentionally skipped on Linux in interactive tests
• Context menus: marked macOS-only in interactive tests
• CEF devtools: only available in

  dev

  builds, at

  http://localhost:9222