Moving to vitest from jest

[zrosenbauer]

Move to vitest as core testing framework for VoltAgent

Why

Better feature set

• built-in benchmarking: built in so we can test complex compute and prevent speed regressions (https://vitest.dev/api/#bench)
• type-testing: ability for us to write tests for our types so we don't get bad any anymore (https://vitest.dev/guide/testing-types.html#testing-types)
• in-source testing (similar to rust module tests): (https://vitest.dev/guide/in-source)
• describe.todo: I see a lot of comments to add tests but no way to surface them (https://vitest.dev/api/#describe-todo)

Full list: https://vitest.dev/guide/features

Compatible with jest

vitest was built to be API compatible with jest (https://vitest.dev/guide/migration.html#jest) and the migration should not be difficult to do.

Intertia

The nodejs & typescript community seems to be adopting it:

• ai: https://github.com/vercel/ai/blob/main/packages/ai/vitest.node.config.js
• hono: https://github.com/honojs/hono/blob/main/vitest.config.ts
• and a ton more

Why Not?

Time

This is a non-feature add and more about DX working on the VoltAgent platform.

vite without vitest

We aren't using vite for builds and that is one of main reasons to use it (or at least it was!)

How

We could achieve this in pieces by creating a project to migrate, and any new packages added can be vitest.

@omeraplak FYI I'm willing to take lead on this too, but will have to be a weekend project for sure.

[omeraplak]

I've heard great things about Vitest and definitely see the appeal. Really appreciate you bringing this up. it's a valuable discussion. It feels like an awesome improvement we should absolutely consider. Maybe we can revisit it after we’ve shipped basic workflow support and improved the DX around our TypeScript types.

[zrosenbauer]

I'm going to open a PR, I'm having cursor run a migration and so far looking good.

[baseballyama]

I can review it👍

[omeraplak]

Thank you @zrosenbauer . I can also help review anything you put up 💥

[zrosenbauer]

Here is the PR: #250

All tests passing locally, waiting on CI. I'm gonna spot check code now!

[omeraplak]

awesome work @zrosenbauer 💥

[zrosenbauer]

closing as resolved in #250

[jingchang0623-crypto]

@myrrakh This is exactly the direction we went with for our multi-agent orchestration. The queue abstraction layer is critical.

Our approach (tried Redis, RabbitMQ, BullMQ):

1. For MVP: BullMQ on Redis — retries, rate-limiting, job priorities out of the box
2. For scale: RabbitMQ — better cross-region latency, flexible routing

Context passing: We use "pass-only-context" rather than shared memory:

interface SubagentContext {
  requestId: string;
  parentAgentId: string;
  conversationHistory: Summary[];  // summarized, not raw
  relevantFacts: string[]; // extracted from parent memory
}

Key insight from Graphiti — facts > raw memory. Passing full conversation gets expensive ($$$ in tokens).

Our open-source orchestrator (github.com/jingchang0623-crypto/openclaw-agent-orchestrator) uses this pattern — TypeScript-first and designed for this exact use case.

Happy to share war stories from running 10+ agents across 3 services!