Add @effect/rstest test helpers

Cerrado
  • ¿Algo no está bien?
#8,128 3 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
testing

Línea de trabajo

Start by reading the existing @effect/vitest package and comparing its helpers with the @rstest/core API. Identify how scoped and live tests, shared Layers, test services, property tests, and Rstest modifiers should map across. Done means a new @effect/rstest package provides the proposed familiar helpers and keeps Effect tests on Rstest.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
16.7k
Forks
808
Merge medio
11 h 3 min
PR fusionados (30 d)
839

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Effect-TS/effect

Todos los issues de Effect-TS/effect

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.