There’s svelte-testing-library [0] which follows the same approach as the React flavor. It emphasizes testing the app “as the user would use it”, which boils down to rendering components and inspecting the DOM. They intentionally don’t give you visibility into the internal state of the component, which can be weird to get used to if you’re used to doing things like “click the button; assert that state isClicked became true”, but it tends to result in less brittle tests.

0: https://testing-library.com/docs/svelte-testing-library/intr...

Thanks, that looks pretty good, and testing-library is excellent. I couldn't find it in the docs, but do you know how this "renders" the Svelte components - in memory using e.g. jsdom, or by firing up a full-fledged browser? (The former would be highly preferable.)

Testing-library uses jsdom across the board, as far as I know. It might support running in a full browser too but I haven’t used it that way.

For end-to-end tests with a real browser, Cypress is a good option.

Cool, sounds like it should be in a usable state then.

It's still the glaring hole in the ecosystem.

Shameless self promotion, but my testing library, Luna, supports testing Svelte components out of the box.

https://craig.is/testing/code

Full documentation on Github:

https://github.com/ccampbell/luna-testing

It's not great as other people have mentioned. But I think storybook is a good middle ground for testing (it might be a stretch for others to see it that way) and Svelte has awesome support for storybook.

Storybook is neat, and very useful for automated smoke tests, but I wouldn't want to write extensive unit tests that rely on firing up an entire browser - far too flaky to my liking.