Promote Storybook testing to h2

[shilman]

Storybook testing docs are currently buried in the page contents. This change makes it visible in the right-hand table of contents.

The current structure also nests Storybook under Vitest, which can be confusing to users. The fact that Storybook uses Vitest under the hood further confuses things. By promoting it to be a peer of Vitest and Playwright, where it belongs, this change should also improve clarity.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

⚠️ No Changeset found

Latest commit: 28e058a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-16792-svelte.vercel.app/

[dummdidumm]

I'm not too sure about this change. Logically it belongs to component testing because that's the context in which it is referenced.

I hear you about the discover-in-the-side-nav-aspect - though I wonder if we should tackle this more generally by adjusting that nav bar to also show h3 entries. Would also make searching for things on other pages much easier (I hate the SvelteKit hooks page for that reason)

[shilman]

@dummdidumm does the current structure actually make sense though? If the page was organized by test types you could put Storybook and Vitest as options underneath a component testing section. But it's currently organized as a peer to the component testing section, which is nested under "Unit and integration testing using Vitest."

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16792

[JReinhold]

If you look at this purely from a topical POV and assume the user has a specific testing strategy in mind when reading the docs, I could suggest a structure like this:

---

Unit Testing

Why unit tests are good, and when

Using Vitest

• How to set up Vitest
• Example of a unit test in Vitest

Component¹ Testing

Why component tests are good, and when

Using Vitest

• How to set up Vitest
• Example of a component test in Vitest

Using Storybook

• How to set up Storybook
• Example of a component test in Storybook

E2E Testing

Why E2E tests are good, and when

Using Playwright

• How to set up Playwright
• Example of an E2E test in Playwright

---

However the structure above has a few downsides:

1. Setting up Vitest for unit or component test is almost the same (if not exactly the same), so it would result in duplicated documentation here, unless we wrote a reference like "See docs on setting up Vitest ablove"
2. The nested approach is a bit verbose for both unit and e2e, given there is only one provider documented - you could argue that those two headings should then be collapsed in the name of conciseness.

Which brings me to something very close to what is there today:

---

Concise summary of unit, component and E2E tests, when to consider which and how they differ.

Unit and Component Testing with Vitest

• How to set up Vitest
• Example of a unit test in Vitest
• Example of a component test in Vitest

Component Testing with Storybook

• How to set up Storybook
• Example of a component test in Storybook

E2E Testing with Playwright

• How to set up Playwright
• Example of an E2E test in Playwright

---

This approach structures the docs around the tools rather than the testing types, while still providing an overview of the testing types via the intro and headings. Maybe this is better? At least it's the most clear structure I can imagine right now.

Maybe @dominikg has input as well.

Footnotes

1. There are as many definitions of what "integration test" means as there are software engineers. Given Svelte is a framework for building UI Components, I'd say that an integration test in relation to Svelte is de-facto a component test, but not a strong opinion. ↩

[Rich-Harris]

I like that structure @JReinhold. I also think we should change 'E2E' to 'End-to-end', since we shouldn't assume everyone is versed in the acronym (it's also just nicer, aesthetically, in the context of a title) and change 'testing' to 'tests'. So we'd end up with this:

[shilman]

Thanks @Rich-Harris @JReinhold and @dummdidumm. I've updated the PR with your heading suggestions!