Writing Testing Library tests that use certain Skeleton components #2891
-
|
I'm working on a project that uses SvelteKit, Skeleton, and Testing Library. What is the best way of using and testing Skeleton components like Popup or Modal in Testing Library tests? Can they be used directly, or do they all need to be mocked? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 11 replies
-
|
Hey @is-sematell, so two things here:
Skeleton tests our own components and features, so you do not need to. That would be redundant. Here's our modals test for example. What you should focus on is testing your own custom modals, which utilize a component embedded within a modal window. In that case, you would test the component (directly in isolation) just like any other, and Outside the scope of the wrapping modal system (which again is already tested on our side). For overlay elements (popovers, modals, etc), those can be a bit harder to test with unit tests (ex: Vitest + Testing Library) since you need a trigger, you need the test to click the trigger, await the modal to display, then test the results. But that is a scenario Testing Library can fulfill. Typically paired with an async task to await the change in interface. You can see a brief example of triggering clicks here: One technique I've used with success here is to create a small co-located component alongside the test that is purpose built to replicate a trigger + modal/popover in isolation. That's the primary goal of unit tests after all - testing as isolated as possible. That's a bit closer to integration testing, due to the extra scaffolding, but still something these tools are equipped to handle. Finally, if you really need to test a feature as it functions in the user flow. That's where e2e testing may be a lot more valuable. You can use testing tools like Playwright for that. As for the specifics for implementing the tests themselves, that's a bit outside the scope of our support. But I would recommend reading through the Testing Library documentation to understand how it operates. However, Skeleton is open source so you can reference our component tests here:
Note that our v3 tests a bit better quality, as we've matured in our understanding of the testing tooling, but currently limited only to our React components. This is due to Vitest and Test Library not having thorough documentation for the Svelte 5 pre-release versions. Now that Svelte 5 has launched, we expect that to change, and of course bring parity to our new components. Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @endigo9740, Thanks for the detailed answer. Just to make it clear, I don't intend on testing Skeleton components directly, that would be way out of scope. I only intend to test our own components that utilize Skeleton components under the hood. Nonetheless, that would indeed require the Skeleton components like Modal or Popup to work with Testing Library. Then the test would have to trigger, for example, a popup, assert its contents, etc. So, how should Skeleton be set up for Testing Library? Would I need to create some kind of wrapper that initializes the Skeleton stores? Are all components fully compatible to work seamlessly in Testing Library, or are there any technical limitations? |
Beta Was this translation helpful? Give feedback.
-
|
By the way, I don't see any test example for Popup. Is there any reason for that? |
Beta Was this translation helpful? Give feedback.
-
|
@endigo9740 I've created a Tooltip component that utilizes Skeleton popup. It works just fine in the browser. However, when I try to test it via Testing Library, I get the below error. Seems like it is caused by Am I missing something, or is this a bug? ErrorReproduction steps
CodeTooltip.svelte<script lang="ts">
import { popup, type PopupSettings } from '@skeletonlabs/skeleton';
export let label: string;
export let target: string;
export let content: string;
const popupHover: PopupSettings = {
event: 'hover',
target,
placement: 'top'
};
</script>
<button class="btn variant-filled [&>*]:pointer-events-none" use:popup={popupHover}>
<span>{label}</span>
</button>
<div class="card p-4 variant-filled-secondary" data-popup={target}>
<p>{content}</p>
<div class="arrow variant-filled-secondary" />
</div>TooltipTest.svelte<script lang="ts">
import { initializeStores, storePopup } from '@skeletonlabs/skeleton';
import { computePosition, autoUpdate, offset, shift, flip, arrow } from '@floating-ui/dom';
import Tooltip from './Tooltip.svelte';
initializeStores();
storePopup.set({ computePosition, autoUpdate, offset, shift, flip, arrow });
</script>
<Tooltip
target="info"
label="More Info"
content="We're going to check if this component can be tested in Testing Library"
/>Tooltip.test.tsimport { render } from '@testing-library/svelte';
import userEvent from '@testing-library/user-event';
import TooltipTest from './TooltipTest.svelte';
describe('TooltipTest.svelte', () => {
it('should render the tooltip content on hover', async () => {
const { getByText, queryByText } = render(TooltipTest);
const triggerElement = getByText('More Info');
await userEvent.hover(triggerElement);
expect(
getByText("We're going to check if this component can be tested in Testing Library")
).toBeVisible();
await userEvent.unhover(triggerElement);
expect(
queryByText("We're going to check if this component can be tested in Testing Library")
).not.toBeVisible();
});
}); |
Beta Was this translation helpful? Give feedback.
-
Skeleton has no special requirements that would require you to use any configuration beyond what Test Library itself requires. If you follow my recommendation above, typically you're just testing components, which is what Vitest with Testing Library is all about.
I'll emphasize again, I can help push you in the right direction (as far as recommendations), but it's outside the scope of our support to teach you how to use Testing Library. I strongly recommend you read through their documentation, look at guides, and understand the plethora of options they provide.
The popup feature historically went through several iterations in Skeleton v1 and v2 and we were never quite satisfied with where it landed. It was never quite a "finished" feature and testing was lacking for some features. We're taking a very different stance in v3, testing will be standardized, and we're changing how v3 popovers and modals are handled. Ownership of these features will now be directly in developer's hands.
Perhaps? But I'm not an expert in Testing Library. I'd suggest bringing up this issue in their support community. |
Beta Was this translation helpful? Give feedback.
-
|
@endigo9740 howdy, svelte-testing-library maintainer here! Would you mind elaborating on this point - I'm always looking to improve documentation:
Svelte 5 shouldn't require any testing setup changes compared to Svelte 4, so I'd love to hear about any issues that you ran into! (As for the bug mentioned above, it's a CSS parsing bug from a child dependency of JSDom, and not an issue in testing-library nor skeleton. Resolution is to use happy-DOM or a real browser, instead.) |
Beta Was this translation helpful? Give feedback.
-
|
@mcous Hey Michael, thanks for reaching out. That's strange, I use Vitest + Test Library for testing Svelte 4 components as part of my day job and am fairly well versed in the process. But I definitely recall we had several issues with Svelte 5 components. To the point we abandoned this with plans to revisit as time allowed. Maybe just user error on our end? Admittedly this has been several months ago, so I can't recall the specifics. But we very much want to bring our Svelte component tests inline with our React components prior to launch. It's one of our final items remaining in fact: We plan to revisit this in the near future (next couple of weeks). Knock on wood everything goes smoothly this time, but would you mind if I reach out directly if we run into similar issues again? |
Beta Was this translation helpful? Give feedback.
-
|
Please do! Very happy to help in either GH or Discord. We're embarking on a similar journey at my work so I have a very vested interest in making sure STL behaves smoothly on all versions. FWIW STL's CI tests Svelte 3, 4, and 5 as well as Jest, Vitest + JSDom, and Vitest + happy-dom. Not to say issues don't exist, but we should be well equipped to fix any such issues without too much fuss! |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, will do then! We're aiming to launch our first beta version next week, so obviously a lot to juggle at the moment. But I wouldn't shy away from a preemptive audit if you have a couple minutes to spare. Just make sure we're not doing something dumb. The Skeleton v3 Svelte component package can be found here: We have a few things in place:
I know we had wrote our own tests at one point, but I think we opted to strip those out to avoid CI failure until we could debug further. Again, no pressure, but it might give us a head start this next go round. Just drop any feedback here and I'll see it: |
Beta Was this translation helpful? Give feedback.
-
|
For anyone who is also running into this issue, I've opened a ticket in the testing-library repo They have suggested two workarounds, and both of them work:
|
Beta Was this translation helpful? Give feedback.
Skeleton has no special requirements that would require you to use any configuration beyond what Test Library itself requires. If you follow my recommendation above, typically you're just testing components, which is what Vitest with Testing Library is all about.
I'll emphasize again, I can help push you in the right direction (as far as recommendations), but it's outside the scope of our support to teach you how to use Testing Library. I strongly recommend you read through their documentation, look at guides, and understand the plethora of options they provide.
https://testin…