DEV Community

Daniel Irvine 🏳️‍🌈
Daniel Irvine 🏳️‍🌈

Posted on


Testing Svelte context with component hierarchies

In the previous part of this series I looked at how to use mocking effectively when testing parent-child component relationships.

But that isn’t the only way of dealing with parent-child components, and component hierarchies in general. In this part I’ll look at testing two components in the same test suite. So far I’ve found this useful when dealing the Svelte’s context API.

All of the code samples in the post are available in this demo repo:

GitHub logo dirv / svelte-testing-demo

A demo repository for Svelte testing techniques

An example

Suppose you create a Menu component and a MenuItem component. Menu is responsible for opening and closing a list of items, and MenuItem represents a single item in that list. Crucially, it’s the MenuItem’s responsibility to close the Menu when it is selected.

Here’s Menu. I’ve simplified this by removing styles and by including only functionality that’s relevant to this post.

<script context="module">
  export const key = {};

  import { setContext } from 'svelte';

  let open = false;

  const toggleMenu = () => open = !open;

  setContext(key, {

<button on:click={toggleMenu} class="icon">Menu</button>
{#if open}
<div on:click={toggleMenu}>
  <slot />
Enter fullscreen mode Exit fullscreen mode

And here’s MenuItem (again, this is a simplified implementation).

  import { getContext, tick } from "svelte";
  import { key } from "./Menu.svelte";

  export let action;

  const { toggleMenu } = getContext(key);

  const closeMenuAndAct = async (event) => {
    await tick();

<button on:click="{closeMenuAndAct}">
  <slot />
Enter fullscreen mode Exit fullscreen mode

Both of these components are coupled in two ways.

First, Menu uses <slot> to display all its children and it’s expected that some of these children will be instances of MenuItem.

Second, both components use the context API to share the toggleMenu function. MenuItems can communicate with the parent by invoking the toggleMenu function, which tells the Menu it’s time to close.

Could we programmatically call the context API to test Menu and MenuItem independently?

As far as I can tell, no we can’t. In order to do these we’d need to manipulate the context API. For example, for the MenuItem we’d need to make available a spy toggleMenu function that we could then assert on to check it was invoked.

it("invokes the toggleMenu context function", () => {
  // ? set up context here ?
Enter fullscreen mode Exit fullscreen mode

Trouble is, there’s no supported way of calling the context API outside of components themselves. We could probably do it by using the component.$$ property in the way we did with bound values in the last part, but that’s at risk of breaking in future.

Besides, these two components are meant to be used together, so why not test them together?

This is one place where React has Svelte beat!

Because React allows inline JSX, we could simply write a test like this:

const menuBox = () => container.querySelector(".overlay");

it("closes the menu when clicking the menuItem", () => {
  mount(<Menu><MenuItem /></Menu>);
Enter fullscreen mode Exit fullscreen mode

Unfortunately Svelte components must be defined in their own files, so we can’t do little inline hierarchies like this.

 Solution: define a test component for each test

In the test repo I have a directory spec/components where I keep little hierachies of components for specific tests. Sometimes the same test component can be used for multiple tests.

Here’s spec/components/IsolatedMenuItem.svelte:

  import Menu from "../../src/Menu.svelte";

  <img alt="menu" slot="icon" src="menu.png" />
Enter fullscreen mode Exit fullscreen mode

There are a couple of tests I can write with this. First, the test that checks the menu is closed.

Here’s spec/Menu.spec.js with just the first test—notice that I named the file after the parent component, but it’s testing both the parent and child.

import { tick } from "svelte";
import { mount, asSvelteComponent } from "./support/svelte.js";
import Menu from "../src/Menu.svelte";
import IsolatedMenuItem from "./components/IsolatedMenuItem.svelte";

const menuIcon = () => container.querySelector(".icon");
const menuBox = () => container.querySelector("div[class*=overlay]");

const click = async formElement => {
  const evt = document.createEvent("MouseEvents");
  evt.initEvent("click", true, true);
  await tick();
  return evt;

describe(, () => {

  it("closes the menu when a menu item is selected", async () => {
    await click(menuIcon());
    await click(menuBox().querySelector("button"));
Enter fullscreen mode Exit fullscreen mode

Notice how similar this is to the React version above. The difference is just that the component exists within its own file instead of being written inline.

(By the way, I think this is the first time in the series that I’ve shown any DOM events... click is something that could be cleaned up a little. We’ll look at that in the next post!)

The second test uses the spy prop of IsolatedMenuItem.

it("performs action when menu item chosen", async () => {
  const action = jasmine.createSpy();
  mount(IsolatedMenuItem, { spy: action });
  await click(menuIcon());
  await click(menuBox().querySelector("button"));
Enter fullscreen mode Exit fullscreen mode

For this test component I named the prop spy, which is used to set the action prop on MenuItem. Perhaps I should have kept its name as action. The benefit of naming it spy is that it’s clear what its purpose is for. But I'm still undecided if that’s a benefit or not.

Use with svelte-routing

I’ve also used this with svelte-routing when I defined my own wrapped version of Route. These classes also use the context API so it’s similar to the example shown above.

In the next (and final!) post in this series, we’ll look at raising events like the one we saw here, the click event, and how we can test components together with more complex browser APIs like setTimeout.

Top comments (1)

maciekgrzybek profile image
Maciek Grzybek

Awesome stuff bud :)

Visualizing Promises and Async/Await 🤓

async await

☝️ Check out this all-time classic DEV post on visualizing Promises and Async/Await 🤓