What is the problem this feature would solve?
@effect/vitest makes Effect tests much nicer to write, especially with helpers such as it.effect, it.live, shared layers, test services, and property tests. There is no equivalent package for Rstest, so projects using Rstest need to build and maintain their own adapter or bring in Vitest just for Effect tests.
We use both Effect and Rstest extensively at Zephyr Cloud. Having the same kind of integration for Rstest would come in handy for us and would let our tests stay on one runner.
What is the feature you are proposing to solve the problem?
Add an @effect/rstest package alongside @effect/vitest.
Ideally it would re-export @rstest/core and provide the familiar Effect helpers for scoped and live tests, shared Layers, TestClock and TestConsole, property tests, and Rstest modifiers such as skip, only, fails, concurrent, and sequential.
The goal would be for an Rstest test to look familiar to anyone already using @effect/vitest:
import { assert, it } from "@effect/rstest"
import { Effect } from "effect"
it.effect("runs an Effect", () =>
Effect.gen(function*() {
const value = yield* Effect.succeed(42)
assert.strictEqual(value, 42)
}))What alternatives have you considered?
We can keep a small local wrapper around Effect.runPromise, but then every project has to solve scope cleanup, test services, timeouts, layers, and typing again. We could also keep Vitest around only for Effect-heavy tests, though using two test runners in the same codebase adds extra configuration and splits the test workflow.
What is the problem this feature would solve?
@effect/vitestmakes Effect tests much nicer to write, especially with helpers such asit.effect,it.live, shared layers, test services, and property tests. There is no equivalent package for Rstest, so projects using Rstest need to build and maintain their own adapter or bring in Vitest just for Effect tests.We use both Effect and Rstest extensively at Zephyr Cloud. Having the same kind of integration for Rstest would come in handy for us and would let our tests stay on one runner.
What is the feature you are proposing to solve the problem?
Add an
@effect/rstestpackage alongside@effect/vitest.Ideally it would re-export
@rstest/coreand provide the familiar Effect helpers for scoped and live tests, sharedLayers,TestClockandTestConsole, property tests, and Rstest modifiers such asskip,only,fails,concurrent, andsequential.The goal would be for an Rstest test to look familiar to anyone already using
@effect/vitest:What alternatives have you considered?
We can keep a small local wrapper around
Effect.runPromise, but then every project has to solve scope cleanup, test services, timeouts, layers, and typing again. We could also keep Vitest around only for Effect-heavy tests, though using two test runners in the same codebase adds extra configuration and splits the test workflow.