Testing SvelteKit load Functions

WHY IT EXISTS: SvelteKit pages and layouts depend on load functions to supply data before any component renders. As applications grow, these functions accumulate business logic like authentication checks, header parsing, database queries, and data transformations. Without a way to test this logic in isolation, developers are forced to rely on slow end-to-end tests or manual UI clicking to catch bugs in data fetching. Testing load functions directly was introduced to give fast, deterministic feedback on the server-side logic that powers routes.

THE MENTAL MODEL: Think of a load function as a controller method in a traditional web framework. It receives a request context, performs work, and returns a data payload. The difference is that SvelteKit hides this inside the framework routing layer. Your job when testing is to treat it like a function with an awkward input type: you construct the minimal request event it needs, call the function, and assert on the returned object. You are not testing the page component, and you are not testing the browser. You are testing the data contract between the server and the UI.

HOW IT WORKS: In a Vitest unit test, import the load function from its module. Build a fake event object containing only the properties your code touches. For a universal load in +page.js, this usually includes url, params, and fetch. For a server load in +page.server.js, you will also need locals, cookies, and possibly request. Mock fetch on the event to return standard Web Response objects with the JSON your route expects. Invoke load with this fake event and await the result. Assert that the returned object contains the correct keys, shapes, and error states. If your load redirects or throws, assert against those behaviors as well.

WHEN TO USE IT: Use isolated load tests when the function contains conditional logic, authorization rules, or data mapping that you want to exercise across many scenarios. It is also valuable when the upstream APIs are slow or flaky and you need deterministic tests that run in milliseconds. If your load function is a critical dependency for multiple pages, unit testing it protects every consumer from breaking changes.

WHEN NOT TO USE IT: Do not write unit tests for load functions that are thin proxies making a single fetch with no logic. In those cases, the integration test or the API contract test already covers the behavior. Also avoid unit testing when your mocks become so elaborate that they replicate SvelteKit internals; brittle mocks that break on framework upgrades are a signal that an integration test or a real request test is the better tool.

ONE CANONICAL EXAMPLE: Imagine a +page.server.js load that reads a user object from locals.user, calls fetch with an authorization header, and returns an account balance. In your Vitest test, create an event where locals.user is an object with an id and a token. Set event.fetch to a stub that resolves to a Response containing JSON with balance and currency. Call load with this event and assert that the returned account object matches the expected shape. If the user is missing, assert that the load throws a redirect or returns an error object depending on your implementation. This test runs in milliseconds and never needs a browser.