Early release. Aver is functional and tested but pre-1.0. APIs may change between minor versions.

Domain-driven acceptance testing for TypeScript. Describe what your system does. Prove it at every level.

const { test } = suite(taskBoard)

test('move task through workflow', async ({ given, when, then }) => {
  await given.createTask({ title: 'Fix login bug' })
  await when.moveTask({ title: 'Fix login bug', status: 'in-progress' })
  await then.taskInStatus({ title: 'Fix login bug', status: 'in-progress' })
})

 ✓ move task through workflow [unit]          1ms
 ✓ move task through workflow [http]         12ms
 ✓ move task through workflow [playwright]  280ms

Lock in what exists. Start with characterization tests that capture your system's current behavior. No domain model needed yet — just prove what's already true.

Name the behaviors. Extract a domain vocabulary — actions, queries, assertions in business language. The domain is the stable center; tests speak only domain language.

Prove it at every level. Write the test once. Bind it to adapters — in-memory, HTTP, browser. Same scenario, same assertions, different fidelity. OTel verification closes the loop: declare expected telemetry on domain operations, and the framework proves not just that spans exist, but that the relationships between them are intact — same trace, correct attributes, causal connections preserved.

Domain (what)  →  Adapter (how)  →  Test (verify)

Five domain operations support fifty tests. Vocabulary grows slowly, scenarios grow fast.

npm install --save-dev @averspec/core vitest
npx aver init
npx aver run

• Tutorial: Legacy Code — From untested code to multi-adapter tests
• Tutorial: Greenfield — Build a domain from scratch
• Tutorial: Telemetry — Verify observability contracts alongside behavior
• Architecture — Three-layer model, design decisions, economics
• Getting Started — Install, scaffold, configure
• Guides — Multi-adapter, telemetry, CI, AI-assisted testing

• Multiple adapters — unit, HTTP, and browser tests share the same scenario
• Acceptance-level verification — behavior tests, not low-level unit logic
• Shared vocabulary — product and engineering need a common language for behavior
• Observability matters — you want to prove telemetry is structurally correct

• Pure unit tests — a plain Vitest test is simpler for isolated functions
• Prototypes or throwaway code — the domain/adapter payoff needs time to compound
• Single deployment target — no HTTP or browser adapter means domain overhead without multi-adapter benefit
• Trivial CRUD — if the domain vocabulary would mirror the database schema, there's nothing to abstract

MIT