Feature: add first-class Astro support

[Nsttt]

What problem does this solve?

Astro projects currently do not have a first-class Rstest integration. Astro's official unit/component testing story is Vite-based: users load Astro config with getViteConfig() and test .astro component output through the experimental Container API.

Because Rstest is currently Rsbuild/Rspack-based, importing .astro files and using Astro-specific virtual modules/renderers is not supported out of the box.

Proposed solution

Add first-class Astro support, likely as an experimental adapter package:

import { withAstroConfig } from '@rstest/adapter-astro';
import { defineConfig } from '@rstest/core';

export default defineConfig({
  extends: withAstroConfig(),
  testEnvironment: 'node',
});

The adapter should allow tests like:

import { experimental_AstroContainer as AstroContainer } from 'astro/container';
import { expect, test } from '@rstest/core';
import Card from '../src/components/Card.astro';

test('renders Astro component output', async () => {
  const container = await AstroContainer.create();
  const html = await container.renderToString(Card, {
    slots: {
      default: 'Card content',
    },
  });

  expect(html).toContain('Card content');
});

Expected scope

• Load astro.config.* and reuse test-relevant configuration.
• Support importing .astro files in Rstest.
• Support Astro Container API tests for props, slots, request, params, locals, and endpoint/page rendering.
• Support official Astro renderers where possible (@astrojs/react, @astrojs/vue, @astrojs/svelte, @astrojs/preact, @astrojs/solid-js, @astrojs/mdx).
• Add e2e fixtures and docs for Astro projects.
• Optionally detect Astro projects in setup/init guidance.

Implementation notes

There are two likely paths:

1. MVP: Rspack loader/plugin backed by @astrojs/compiler, enough for server-side .astro component tests.
2. Higher fidelity: introduce a Vite-backed compile path or Vite adapter, then build @rstest/adapter-astro on top of Astro's own Vite config helpers.

The first path is smaller and fits Rstest's current architecture. The second path is likely closer to Astro's official testing model, especially for virtual modules, integrations, CSS/assets, and content-related features.

References

• Astro testing docs: https://docs.astro.build/en/guides/testing/
• Astro Container API: https://docs.astro.build/en/reference/container-reference/
• Astro integrations: https://docs.astro.build/en/guides/integrations-guide/

[fi3ework]

Thanks for the detailed proposal! A few thoughts on scoping before this moves forward:

On the adapter layer: adapter-rsbuild / adapter-rslib are fairly thin config-translation shims (~60–130 LoC each) — they mostly map config fields rather than extending bundler capabilities. So a @rstest/adapter-astro package on its own probably wouldn't be enough to land Astro support; the harder pieces sit a layer below.

The main challenge: there isn't really an Astro compiler for Rspack/webpack today. .astro compilation, astro:* virtual modules, integration hook injection, and the runtime that experimental_AstroContainer depends on are all implemented as Vite plugins on top of @astrojs/compiler. Without Rspack-side equivalents, importing a .astro file would fail at the bundler level, so the foundational piece would need to land before anything Rstest-specific can be built on top.

For Path 1 (Rspack-native), the work would roughly look like:

1. An .astro loader for Rspack/webpack on top of @astrojs/compiler.
2. Rspack equivalents (or shims) for the astro:* virtual modules and integration hooks the Container API needs.
3. A thin adapter wiring Astro config into Rstest — fairly straightforward once 1 and 2 exist.

Path 2 (Vite-backed compile) is interesting because it could reuse Astro's own Vite plugins for 1 and 2, but it would mean running a Vite pipeline alongside Rstest's Rsbuild/Rspack one — a fairly significant architectural shift, so probably worth more discussion before going that direction.

Either way, most of the heavy lifting sits below the adapter layer, which is what makes this tricky to scope as a single package today. Once a .astro Rspack loader and the related virtual-module support exist in the ecosystem, building @rstest/adapter-astro on top should be fairly straightforward, and we'd be happy to pick it up at that point.

[Nsttt]

Sound good !