[jest] Add an example of testing using jest

Hello, could you add some example of testing a component that uses Routify (or its part like url)?

This would improve our experience and avoid struggling with configuration in the future.

For example, I built my project from scratch using npx @roxi/routify@next create my-r3-app, then installed necessary packages (npm i --save-dev jest babel-jest svelte-jester @testing-library/svelte babel). However, still encounter an error - referring to ESM support - like:

ReferenceError: module is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension 
and '/home/.../svelte/my-r3-app/package.json' contains "type": "module". 
To treat it as a CommonJS script, rename it to use the '.cjs' file extension.

version 3. But also related to the 2

files babel.config.js:

module.exports = {
  presets: [
    [
      "@babel/preset-env",
      {
        targets: {
          node: "current"
        }
      }
    ]
  ],
  plugins: ["@babel/plugin-transform-modules-commonjs"]
};

jest.config.js:

module.exports = {
  transform: {
    "^.+\\.svelte$": [
      "svelte-jester",
      {
        "preprocess": true
      }
    ],
    "^.+\\.ts$": "ts-jest",
    "^.+\\.js$": "babel-jest"
  },
  moduleFileExtensions: [
    "js",
    "ts",
    "svelte"
  ]
};

Note: see discussion at the Discord #general channel.

[jakobrosenberg]

Thanks for the solution @cooperwalbrun . I might include a link to your post. 🙂

[cooperwalbrun]

Alright, I did some tinkering with mocking in Jest and I managed to come up with a solution that allows for a little more flexibility in mocked values (thanks @jakobrosenberg for pointing me to your custom framework; it helped guide me to the answer).

Below demonstrates how to mock specific Routify helper functions using Jest such that rendering components which depend on them causes no errors. @jakobrosenberg I am not sure whether you would want to include this example somewhere in the Routify documentation?

import type { Readable, Unsubscriber } from 'svelte/store';
import type { IsActiveHelper, UrlHelper } from '@roxi/routify/typings/runtime/helpers';
import { derived, readable } from 'svelte/store';

const mockIsActive: IsActiveHelper = path => true; // Customize this based on your unit test
const mockUrl: UrlHelper = path => path; // Customize this based on your unit test

function mockAggregator<T>(value: T, setter: (value: T) => void): void | Unsubscriber {
  // Do nothing; there is no reason to aggregate value changes because we hard-code the returned
  // values in mockIsActive and mockUrl above
}

jest.mock('@roxi/routify', () => {
  // These mock store definitions must be defined here (instead of e.g. global scope) because Jest
  // will automatically hoist the jest.mock() call to the top of the file, and if isActiveStore or
  // urlStore were defined in global scope, they would be undefined at the point in time this mock
  // is being invoked.
  // See: https://www.bam.tech/article/fix-jest-mock-cannot-access-before-initialization-error
  const isActiveStore: Readable<IsActiveHelper> = {
    subscribe: (run, invalidate) =>
      derived(readable<IsActiveHelper>(), mockAggregator, mockIsActive).subscribe(run, invalidate)
  };
  const urlStore: Readable<UrlHelper> = {
    subscribe: (run, invalidate) =>
      derived(readable<UrlHelper>(), mockAggregator, mockUrl).subscribe(run, invalidate)
  };

  return {
    // Add other Routify mocks here as needed
    isActive: isActiveStore,
    url: urlStore
  };
});

test('my test', () => {
   // Render your Svelte component(s) as usual
});

Additional Findings

Interestingly, when I tried doing this:

derived(readable(mockIsActive), mockAggregator).subscribe(run, invalidate)

I received internal Svelte errors in my tests. I had expected this derived usage to work the same as

derived(readable(), mockAggregator, mockIsActive).subscribe(run, invalidate)

because the API documentation suggests that these are simply different ways to express the same thing, but that does not appear to be the case. Anyway, this is not an issue in practice because the latter approach works fine - I just wanted to call it out here for awareness.