verify-changes

Featured

How to test and verify work in the dev-3.0 repo — which vitest config covers what, how to write a test that fits the house style, mocking Electrobun RPC and i18n providers, what coverage is actually expected, and the browser QA hand-off. Use when writing or fixing tests, deciding what a change needs covered, hitting a failing or flaky suite, or preparing a change for review. Triggers — "write tests for this", "which config runs this", "how do I mock the RPC", "is this covered enough", "the suite is failing".

Code & Development 256 stars 31 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 88/100

Stars 20%
80
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# verify-changes — testing and verification in dev-3.0 The two hard gates (lint + touched tests before push, full suite before a PR) live in `AGENTS.md` and apply whether or not you read this file. Everything here is the detail behind them: which runner covers what, how to write a test that fits, and what "enough" means. ## Which config runs what **Vitest** with `happy-dom` and React Testing Library. Three configs, three independent processes: | Config | Covers | Script | |---|---|---| | `vitest.config.ts` | renderer (`src/mainview/`) | part of `bun run test` | | `vitest.config.bun.ts` | backend (`src/bun/`) | `bun run test:bun` | | `vitest.config.cli.ts` | CLI (`src/cli/`) | `bun run test:cli` | ```bash bun run test # mainview + bun + cli in parallel, minus 3 slow e2e files (~6s) bun run test:full # everything incl. slow e2e (~42s) — CI/PR only bun run test:watch # watch mode ``` Running vitest directly (outside `bun run`): `bunx vitest run`, never `npx`. Narrowing while iterating: `bunx vitest run <path>`, `-t "<test name>"`, `--repeat <n>` for suspected flakes. Because the three configs are separate processes, a failure in one says nothing about the others — read which prefix (`[mainview]` / `[bun]` / `[cli]`) failed. **Local E2E policy:** do not run the full E2E suite locally — `bun run test:full` and any equivalent unfiltered command are reserved for CI/PR validation. Investigating a specific behavior means running that one E2E file or test case. ...

Details

Author
h0x91b
Repository
h0x91b/dev-3.0
Created
6 months ago
Last Updated
today
Language
TypeScript
License
Apache-2.0

Integrates with

Vitest · Testing

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Listed

vitest-testing

How this repo runs Vitest — coverage gate, v8 per-file thresholds, mocking/type-testing patterns. Use for "coverage is failing", "mock this module", or when editing vitest.config.ts, writing/fixing a mock (vi.mock, vi.spyOn, vi.hoisted), or adding expectTypeOf assertions. Pairs with tests.md. Not for generic Vitest questions unrelated to this repo.

0 Updated today
monte3l
Code & Development Solid

verify

Proves a change actually works and root-causes failures — the suite runs first, output actually read. Answers "does it work", where inspect answers "is it good".

10 Updated yesterday
saleh-alhaddad
Testing & QA Listed

verify

Verify an engine change end-to-end by rendering the bundled fixture (examples/local-demo) and inspecting the output MP4 and intermediates. Use when the user says "verify", "run the smoke test", "e2e this change", "does the fixture still render", or before committing a nontrivial engine change. Knows the gotchas: OPENAI_API_KEY (or a local OPENAI_BASE_URL server) is needed for voice/captions but not probe/record/compose, stage-by-stage re-runs beat full re-renders, AIDEMO_KEEP_TMP=1 keeps .compose-tmp for compose debugging, logs/fail-*.png from failed takes. Do NOT use for: recording real product demos (use record-demo) or doc-only changes with no runtime surface.

7 Updated yesterday
tandryukha