Effect-TS: Fix Layer.mock With Partial Mocks

Nov 29, 2025 by Admin 45 views

Hey guys! Today, we're diving into a quirky issue in Effect-TS related to Layer.mock. Specifically, it's about how Layer.mock behaves when you're trying to create partial mocks, especially when some of the unmocked methods or properties don't return Effect. Let's break it down and see how to tackle this. Buckle up; it's gonna be an insightful ride!

The Problem: Partial Mocks and Non-Effect Methods/Properties

So, you're trying to use Layer.mock to mock only a part of your context, leaving the rest untouched. Sounds reasonable, right? But what happens when those untouched methods or properties aren't returning Effect? That's where the trouble begins. Let's illustrate with an example:

class Test extends Context.Tag('Test')<
    Test,
    {
      foo: () => void,
      bar: () => void,
    }
>() {
}

Layer.mock(Test, {
  foo: () => {},
})
// ^ TS2345: Argument of type { foo: () => void; } is not assignable to parameter of type { foo: () => void; bar: () => void; }
// Property bar is missing in type { foo: () => void; } but required in type { foo: () => void; bar: () => void; }

In this scenario, you'd expect Layer.mock to accept the partial mock, but instead, you get a TypeScript error complaining about missing properties. It's as if Layer.mock is enforcing that you provide all methods, even if you only want to mock a subset.

Why is this happening?

The issue arises from how TypeScript and Layer.mock interact. When you provide a partial object, TypeScript checks if it's assignable to the full type. If some properties are missing and those properties are required, TypeScript throws an error. This behavior becomes particularly noticeable when dealing with methods or properties that don't return Effect because Effect types often have more flexible handling due to their nature.

Expected Behavior

The expected behavior is that Layer.mock should gracefully accept partial mocks, regardless of whether the unmocked methods or properties return Effect. It should allow you to mock only the parts you need without forcing you to implement the entire interface.

Observed Behavior

Instead, you get a TypeScript error that prevents you from creating the mock unless you provide implementations for all methods and properties, even those you don't intend to mock. This can be quite frustrating, especially when dealing with complex contexts.

Diving Deeper: Real-World Use Case

Let's consider a real-world scenario. Suppose you're working with @effect/platform's Path and want to create a mock for testing purposes. The Path interface has several methods, most of which are plain functions (i.e., they don't return Effect).

const mockPath = Layer.mock(Path.Path, {
  resolve: (...args: string[]) => [...args].join(sep),
} as Path.Path)

In this case, you might want to mock only the resolve method while leaving the rest as is. However, Layer.mock won't accept this partial mock directly. You're forced to use a type assertion (as Path.Path) to bypass the TypeScript error. While this works, it's not ideal because it obscures the type safety that Effect-TS aims to provide.

Solutions and Workarounds

So, how do we solve this? Here are a few approaches you can take to work around this issue:

1. Provide Complete Mock Implementations

The most straightforward solution is to provide complete implementations for all methods and properties in your mock. This satisfies TypeScript's type checking and allows Layer.mock to work without errors.

class Test extends Context.Tag('Test')<
    Test,
    {
      foo: () => void,
      bar: () => void,
    }
>() {
}

Layer.mock(Test, {
  foo: () => {},
  bar: () => {},
})

However, this approach can be cumbersome, especially if you only need to mock a small part of the context. It also adds unnecessary boilerplate to your tests.

2. Use Type Assertions

As shown in the @effect/platform example, you can use type assertions to tell TypeScript to ignore the type mismatch. This allows you to provide a partial mock without errors.

const mockPath = Layer.mock(Path.Path, {
  resolve: (...args: string[]) => [...args].join(sep),
} as Path.Path)

While this works, it's not ideal because it bypasses TypeScript's type checking. This can lead to runtime errors if the mock doesn't fully implement the interface.

3. Create a Helper Function

To avoid repeating the type assertion and to provide a more type-safe solution, you can create a helper function that merges the partial mock with a default implementation.

function createPartialMock<T>(partial: Partial<T>): T {
  return partial as T;
}

const mockPath = Layer.mock(Path.Path, createPartialMock({
  resolve: (...args: string[]) => [...args].join(sep),
}))

This helper function tells TypeScript that the partial mock is a complete implementation of the interface. It's still a form of type assertion, but it's more localized and easier to manage.

4. Modify Layer.mock (Advanced)

If you're feeling adventurous, you can modify the Layer.mock function to accept partial mocks directly. This would involve changing the type definition of Layer.mock to allow for partial implementations.

// Hypothetical modification to Layer.mock
function Layer_mock<T extends Context.Tag<T, I>, I>(tag: T, mock: Partial<I>): Layer<T>

However, this approach requires a deep understanding of Effect-TS internals and may not be feasible in all cases. It's also possible that future versions of Effect-TS will address this issue directly, making your modification unnecessary.

Conclusion

The Layer.mock issue with partial mocks and non-Effect methods/properties can be a bit of a pain, but there are several ways to work around it. Whether you choose to provide complete mock implementations, use type assertions, or create a helper function, the key is to understand the trade-offs and choose the approach that best fits your needs.

Keep in mind that Effect-TS is continually evolving, and it's possible that future versions will address this issue directly. In the meantime, these workarounds should help you create effective mocks for your tests. Happy coding, and keep those Effects flowing!

In summary, when you're creating mocks using Layer.mock, be mindful of how it handles partial implementations, especially when dealing with methods or properties that don't return Effect. By understanding the issue and applying the appropriate workaround, you can ensure that your tests are accurate, reliable, and maintainable.