testing-library/svelte-testing-library

Svelte 5 feedback and support

stefanhoelzl opened this issue · 41 comments

stefanhoelzl commented

Hello, @mcous has hijacked this post! We've launched experimental Svelte 5 support in @testing-library/svelte. See the Svelte 5 section in the README for setup instructions. No special setup is required to use Svelte 5 if you are using Vitest.

If you find bugs or have other Svelte 5 testing feedback, please add it to this thread! Svelte 5 is still changing rapidly at the time of writing, so feedback is appreciated!

Original post below

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch @testing-library/svelte@4.0.5 for the project I'm working on to use svelte 5.

This patches some breaking changes but there might be more work to do for a proper PR (are tests still working? support svelte 4 and 5, maybe more)

But for everyone who likes to try out svelte 5 this patch should be a good starting point.

Here is the diff that solved my problem:

diff --git a/node_modules/@testing-library/svelte/src/pure.js b/node_modules/@testing-library/svelte/src/pure.js
index 04d3cb0..2f041e0 100644
--- a/node_modules/@testing-library/svelte/src/pure.js
+++ b/node_modules/@testing-library/svelte/src/pure.js
@@ -3,7 +3,7 @@ import {
   getQueriesForElement,
   prettyDOM
 } from '@testing-library/dom'
-import { tick } from 'svelte'
+import { tick, createRoot } from 'svelte'
 
 const containerCache = new Set()
 const componentCache = new Set()
@@ -54,18 +54,15 @@ const render = (
     return { props: options }
   }
 
-  let component = new ComponentConstructor({
+  let component = createRoot(ComponentConstructor, {
     target,
-    ...checkProps(options)
+    ...checkProps(options),
+    ondestroy: () => componentCache.delete(component)
   })
 
   containerCache.add({ container, target, component })
   componentCache.add(component)
 
-  component.$$.on_destroy.push(() => {
-    componentCache.delete(component)
-  })
-
   return {
     container,
     component,
@@ -73,18 +70,14 @@ const render = (
     rerender: (options) => {
       if (componentCache.has(component)) component.$destroy()
 
-      // eslint-disable-next-line no-new
-      component = new ComponentConstructor({
+      component = createRoot(ComponentConstructor, {
         target,
-        ...checkProps(options)
+        ...checkProps(options),
+        ondestroy: () => componentCache.delete(component)
       })
 
       containerCache.add({ container, target, component })
       componentCache.add(component)
-
-      component.$$.on_destroy.push(() => {
-        componentCache.delete(component)
-      })
     },
     unmount: () => {
       if (componentCache.has(component)) component.$destroy()

This issue body was partially generated by patch-package.

jsorb84 commented

Thank you for this, this works flawlessly, you should def. make a pull request , cheers my friend.

jakebottrall commented

Thanks @stefanhoelzl, this is working a treat! Any ideas on how to test snippets? So far I haven't managed to figure out how to provide a snippet to the props API. So it's back to the old slots hack of making a wrapping component for tests.

sureshjoshi commented

Anyone have any luck with snippets? The wrapper components are boilerplate-laden - was hoping to not have to do that.

If anyone has any pointers, I'm happy to give it a shot myself.

sureshjoshi commented

EDIT: Ignore this part - after a LOT of debugging, this seems to be a problem when using happy-dom instead of jsdom - which is insane, since I use happy-dom in all of my other projects... But that's a problem for another day :)

Also, @yanick - for this patch, does screen.debug() work anymore? I can't seem to even get the most basic Svelte component to work due to:

PrettyFormatPluginError: Cannot read properties of null (reading 'toLowerCase')

And that's even with a component which is just <div></div>

mcous commented

I've been messing around with Svelte 5 in our existing test suite, and have encountered the following issues so far. I didn't see any of these explicitly called out in the change log, but I'm assuming at the moment that they're all intentional.

  • onMount and onDestroy are attached / called asynchronously, outside of the component creation / DOM mount
    • Judicious addition of act() can get the tests passing; if you render then unmount immediately, neither onMount nor onDestroy will be called
    • If we want to guarantee that render will call onMount, we'll need to make render async
  • anchor option has been removed from createRoot
  • Element.animate seems to be required to run animations at all, which will require faking something in jsdom/happy-dom to test components with animations
  • Weird happy-dom issue mentioned in comments above
  • 👍1
sysmat commented
  • in which version of this library is this?
  • @testing-library/svelte: 4.1.0, "svelte": "5.0.0-next.55", tests not working
Instantiating a component with `new` is no longer valid in Svelte 5
mcous commented

Rudimentary support for Svelte 5 has been released on the next tag

npm install —-save-dev @testing-library/svelte@next

Since Svelte 5 itself is not ready, expect issues and breaking changes if you try it out!

  • 🎉1
  • ❤️1
sysmat commented

@mcous thx, so @testing-library/svelte@next is "@testing-library/svelte": "^4.2.0",

with this version it works

mcous commented

FYI for those following along: as of the latest svelte prerelease, our own Svelte 5 support will no longer work due to sveltejs/svelte#10516, which removed the API we were using to mount components. Will do our best to adjust accordingly

  • 👀1
yanick commented

as of the latest svelte prerelease, our own Svelte 5 support will no longer work due to sveltejs/svelte#10516

:darth vader big NOOO:

sureshjoshi commented

@mcous If you have any suggestions for directed ways to help, I'm all ears :) Though, less familiar with the internals of the lib.

Is the issue that they removed the API call we use? And that it needs to be migrated to the new one? Or is the new mount API a no-go?

pboling commented

Anyone know of any updates?

mcous commented

Experimental Svelte v5 support is available on the next dist tag

npm install --save-dev @testing-library/svelte@next

In your test files:

import { render } from '@testing-library/svelte/svelte5'

@yanick how would you feel about bumping the next branch to 5 (to account for breaking changes semantic-release missed) and merging into main? Are there any more breaks - e.g. dropping svelte@3 - that you'd like to collect on next first?

The svelte@5 support is appropriately marked as experimental and it seems like something we can promote in a minor release whenever svelte@5 goes into production

pboling commented

Your previous update noted that Svelte 5 support did not work at all. It isn't clear from this update if it has been fixed.

yanick commented

Fwiw, I'm kinda busy today, but I'll try to turn my attention to deployment tomorrow.

mcous commented

Your previous update noted that Svelte 5 support did not work at all. It isn't clear from this update if it has been fixed.

It has been fixed for now, it may be broken tomorrow. With the very-in-progress nature of Svelte v5, the best way to find out if it's currently working will be to try it yourself

  • 👍1
sureshjoshi commented

When I tried testing-lib out a week or so ago, it was working - but also note that there are still bugs depending on whether you're using JSDom vs Happy-Dom, or from svelte itself, or any related libraries.

I've been working on a Svelte 5 headless UI port, and Svelte5 + interop is a bit messy at the moment (to say the least) :)

  • ❤️1
mcous commented

Experimental Svelte 5 support has landed in main! We'll do our best to stay on top of things, but here there be dragons 🐉

npm install --save-dev @testing-library/svelte@latest now includes Svelte v5 support

  • ❤️3
  • 🚀5
MatthewTFarley commented

When using svelteTesting Vitest setup function with Svelte 5, the autoCleanup option does not work because the function imports the Svelte 4 cleanup function by way of vitest.js.

I have also run into the Element.animate issue @mcous identified. Here's an example repository demonstrating it. It also has some comments mentioning the cleanup issue in the vite.config.ts file. Using vitest globals: true is a workaround since it will cause the correct cleanup to run here.

mcous commented

When using svelteTesting Vitest setup function with Svelte 5, the `autoCleanup option does not work because the function imports the Svelte 4 cleanup function by way of vitest.js.

...Using vitest globals: true is a workaround...

@MatthewTFarley auto-cleanup via plugin works if you use the suggested Svelte 5 alias setup from the README! Otherwise, globals mode is probably your best bet. This awkwardness will go away once Svelte 5 is out of prerelease and the svelte5 import is no longer needed.

export default defineConfig({
  plugins: [svelte(), svelteTesting()],
  test: {
    alias: {
      '@testing-library/svelte': '@testing-library/svelte/svelte5',
    },
  },
})

I have also run into the Element.animate issue

I wonder what's going to happen here! The animations work in the browser, but neither jsdom nor happy-dom support Element.animate. I don't know if Svelte's intention is to require Element.animate or include some sort of fallback.

We may have to start thinking about shipping our own Element.animate stub, but faking out browser APIs in this library gets into some iffy-mocking-practices territory

pboling commented

@mcous I don't know enough to know if what I have should be working, or is expected to be broken. I am on latest versions as of this second of all packages, and latest "next" versions where possible (e.g. Svelte 5 next 118). I have some basic tests working, following the patterns of the internal tests of this actual library (testing-library/svelte-testing-library). I'm trying to ensure my config remains working as Svelte5 nears release, and as I add more complex tests to my test suite, so I am following this issue.

When I use the alias mentioned above and in the readme, my test suite doesn't run:

 FAIL  src/lib/components/forms/input.test.ts [ src/lib/components/forms/input.test.ts ]
Error: Missing "./svelte5/vitest" specifier in "@testing-library/svelte" package
 ❯ e node_modules/.pnpm/vite@5.2.10_@types+node@20.12.7/node_modules/vite/dist/node/chunks/dep-DkOS1hkm.js:47596:25

My config (after adding the alias):

import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vitest/config';
import { paraglide } from '@inlang/paraglide-sveltekit/vite';
import { svelteTesting } from '@testing-library/svelte/vite';
export default defineConfig(({ mode }) => ({
	plugins: [
		paraglide({
			// recommended
			project: './project.inlang',
			outdir: './src/lib/paraglide',
		}),
		sveltekit(),
		svelteTesting(),
	],
	resolve: {
		conditions: mode === 'test' ? ['browser'] : [],
	},
	test: {
		include: ['src/**/*.{test,spec}.{js,ts}'],
		environment: 'jsdom',
		setupFiles: ['./vitest-setup.ts'],
		alias: {
			'@testing-library/svelte': '@testing-library/svelte/svelte5',
		},
	},
}));

When I remove the alias property from test I am able to run my test suite. Hopefully this is helpful feedback!

mcous commented

@pboling Looks like maybe our alias needs to be more specific; it's replacing imports it shouldn't. I'll experiment with this a little and update the README shortly. Upon further inspection, I think the problem might lie with a couple updates you should make to your config now that you're using the new svelteTesting plugin.

  • Remove import '@testing-library/svelte/vitest' from your ./vitest-setup.ts file
  • Remove the manual configuration of resolve.conditions

Both of these jobs the plugin now handles for you. I find that this configuration - as listed in the README - behaves well with Svelte 5:

// vite.config.ts
// ...
export default defineConfig({
  plugins: [sveltekit(), svelteTesting()],
  test: {
    include: ['src/**/*.{test,spec}.{js,ts}'],
    environment: "jsdom",
    alias: {
      "@testing-library/svelte": "@testing-library/svelte/svelte5",
    },
    setupFiles: ["./vitest-setup.ts"],
  },
});
// vitest-setup.ts
// Only needed to configure `@testing-library/jest-dom`
import '@testing-library/jest-dom/vitest`

If this doesn't work, you could try using a more specific alias. In my own projects, this is necessary only if I'm not using the svelteTesting plugin.

{
  // ...
  test: {
    // ...
    alias: [
      {
        find: /^@testing-library\/svelte$/,
        replacement: '@testing-library/svelte/svelte5',
      },
    ],
  // ...
  },
}

(All this being said, something feels off to me here. I think having a separate Svelte 5 import path is probably causing more trouble than it's worth. I don't think the situation will stick around too much longer, though)

  • 🚀1
pboling commented

@mcous The top suggestions you gave are working! I did not need the more specific alternative alias.

  • 🎉1
webJose commented

I have a problem testing prop updates. I may be doing it wrong, though.

I am using rerender() to pass updated prop values. Is this the correct way? If it is, then the problem I have is that it seems to cause the component to unmount, which is not expected.

If rerender() is not the right replacement for <component>.$set(), please let me know.

mcous commented

[rerender] seems to cause the component to unmount, which is not expected.

@webJose this was a previous bug with rerender that was fixed in February of this year - see #261. Are you on the latest version of @testing-library/svelte? I'm seeing our own rerender tests passing correctly in CI

svelte-testing-library/src/__tests__/rerender.test.js

Lines 8 to 15 in 326fb58

test('updates props', async () => {
const { rerender } = render(Comp, { name: 'World' })
const element = screen.getByText('Hello World!')
await rerender({ name: 'Dolly' })
expect(element).toHaveTextContent('Hello Dolly!')
})

webJose commented

Hello, yes I'm on the latest version. It was actually my bad. It was an error post-test. To be clear, the unmounting was taking place after the test had finished.

But then I have a different problem. I do await component.rerender(...), but the associated $effect() doesn't seem to be running, and the component seems to be working fine. So I wonder if three could be a different problem. I suppose that $effect()'s are working fine in this library?

mcous commented

@webJose do you have a minimal reproduction of this issue? I just tried out a simple $effect test locally and effects seem to be running correctly

test('$effect', async () => {
  const onEffect = vi.fn()
  const { rerender } = render(Comp, { name: 'World', onEffect })

  await rerender({ name: 'Planet' })

  expect(onEffect).toHaveBeenCalledWith('Planet')
})
<script>
  let { name = 'World', onEffect } = $props()

  $effect(() => {
    onEffect(name)
  })
</script>
webJose commented

@mcous Thank you very much for the time you spent trying to help me.

My problem was related to a deeper async tree. Merely awaiting rerender(), for my specific case, was not enough for everything that I was expecting to happen, happen.

I have now obtained the expected test result by adding an await delay(0); to place the rest of the test's code at the end of the NodeJS message pump. For other people's reference, this is the delay() function:

export function delay(ms: number) {
    let rslv: () => void;
    const promise = new Promise<void>((rs, rj) => {
        rslv = rs;
    });
    setTimeout(() => {
        rslv();
    }, ms);
    return promise;
};
  • 👍1
Hugos68 commented

Hey, I am building a library with Svelte related utilities and wanted to know wether it's possible to test against SSR output. Currently the render function renders the component as it would on the client. But I would really appreiciated if you could do:

render(App, ..., { ssr: true });

Has this been thought of?

Svelte exposes a render function from svelte/server which can be used I think.

mcous commented

Hi @Hugos68, I think that request would be better suited for its own ticket. But short version: no, to my knowledge this hasn't been something on our radar. This library has always been focused on wrapping Svelte's client-side API to render components into a DOM to interact with and run queries against

  • 👍1
mcous commented

I've started work on moving our Svelte 5 support into the non-experimental phase. I've just published @testing-library/svelte@5.2.0-next.1 on our next tag that incorporates Svelte 5 support into the main export; no alias to @testing-library/svelte/svelte5 required

I'll be testing these next versions out before promoting them to our latest tag, and I'd appreciate any help and feedback I could get from anyone else dabbling in Svelte 5!

  • 👍4
  • ❤️4
mcous commented

Followup on my above post: after a few prerelease versions to sort out types and peer dependencies, Svelte 5 support has landed in version 5.2.0 of @testing-library/svelte on our latest tag. Special setup for Svelte 5 should no longer be needed (if you use Vitest)

I'll keep this thread going while Svelte 5 is still itself a prerelease, and as always, please reach out if you run into any issues!

  • 👍2
eunukasiko commented

Is $bindable supported?

This test fails with component.value being undefined

    const user = userEvent.setup();
    const { getByRole, component } = render(Textarea);

    await user.type(getByRole('textbox'), 'bar');

    await waitFor(() => expect(component.value).toBe('bar'));

Textarea has value = $bindable(undefined)

mcous commented

@eunukasiko what does you component look like? I don't think Svelte 5 allows accessing prop values directly on the component instance like that.

You likely will have to use a fixture component and a state rune to test binding, as in the Svelte 4 example, which uses a store

One developer to another: consider avoiding bindable props entirely. Using a prop and a callback function to clearly mark data down and data up, respectively, results in more testable and maintainable code in the long run

  • 👍2
webJose commented

Hello. I have a problem: It seems that with v5.2.0, it is an all or nothing with Svelte 5. Or am I doing something wrong? My scenario is a Svelte v4 component library that is in the middle of the process of being converted to Svelte v5. As such, there are both v4 and v5 components.

The error I get:

 FAIL  src/lib/Alert/Alert.test.ts > Alert > Should render the contents of the default slot.
Svelte error: lifecycle_function_unavailable
`mount(...)` is not available on the server

Only very few tests are passing. For example, this one passes:

    test('Should apply any additional classes passed through the class property.'), () => {
        // Arrange.
        const cssClass = 'my-custom-class';

        // Act.
        render(Alert, { class: cssClass });

        // Assert.
        const alert = screen.getByRole('alert');
        expect(alert).toBeTruthy();
        expect(alert.classList.contains(cssClass)).toEqual(true);
    };

But this one doesn't:

    test.each(allBootstrapVariants)
        ('Should render an alert of the %s variant.', (variant) => {
            // Act.
            render(Alert, { variant });

            // Assert.
            const alert = screen.getByRole('alert');
            expect(alert).toBeTruthy();
            expect(alert.classList.contains(`alert-${variant}`)).toEqual(true);
        });
mcous commented

@webJose that looks like an SSR vs browser import setup bug. What does your Vite / Vitest setup file look like? Does it match the recommended setup in the readme or setup docs?

The Vite plugin this library exports ensures Svelte's browser code is used during tests. Without the plugin, Svelte's SSR code will be used, instead, which won't work properly

webJose commented

Nooo! There's a Vite plug-in? So in Svelte v4 I've been testing SSR? I'll see about this tomorrow.

mcous commented

So in Svelte v4 I've been testing SSR?

Maybe! It was a really long-standing setup bug: #222. We introduced a Vite plugin to make the setup less error prone.

In Svete 4, the SSR code gets used silently. In Svelte 5, it seems to fail, instead. I hope this is your issue, because the fix is easy! If not, hopefully we can figure out whatever else is going on

lachlancollins commented

Hi there, I've created a separate issue #394 because I didn't want to clutter this feed too much, I would appreciate it if anyone following along could have a look!

  • 👍1