🐛 BUG: Vitest mocks fail when test reruns in watch mode

[alfredtan]

Which Cloudflare product(s) does this pertain to?

Workers Vitest Integration

What version(s) of the tool(s) are you using?

3.78.10 [Wrangler], 2.0.5 [Vitest], 0.5.10 [vitest-pool-workers]

What version of Node are you using?

20.13.1

What operating system and version are you using?

Mac Sonoma 14.6.1

Describe the Bug

Observed behavior

I'm new to Vitest and mocking, but I want to try to implement unit test on my Functions app. I'm not sure if I'm implementing it right, but I have researched as much as I can to get it working for Functions, but i'm hitting this "roadblock".

I have an onRequest route (file i want to test) that is importing and calling a class file (with a method I am mocking). My test passes when I run the test but when it runs again when triggered via file save (without changing anything) or using the 'play' button on the Vitest ui, it fails.

I tried it on a clean Vitest project (without Cloudflare) and I'm not seeing this behavior (it always passes).

I created a clean worker repo (using npm create cloudflare) to reproduce this:
https://github.com/alfredtan/vitest-cloudflare-undefined

I'm not sure if i missed anything obvious, appreciate any help!

Expected behavior

Tests should pass on rerun

Steps to reproduce

Clone the given repo and follow instructions in README

Please provide a link to a minimal reproduction

https://github.com/alfredtan/vitest-cloudflare-undefined

Please provide any relevant error logs

No response

[Codex-]

I've run into this today

Seems mocks are not shared correctly on re-runs in watch mode 🤔

Can be reproduced easily by mocking, setting a property on the mocked module and logging in places it's used, can observe the mock is not reused or shared after the initial setup

[alfredtan]

Hey @Codex-, just yesterday i managed to get it working. I'm not sure why the documented mock approach doesn't work (could be my understanding).

i faced a couple of issues, not sure if related: The rerun fails (as per this ticket), and I can't change my mocks between tests. After searching for weeks, I read something about vi.spyOn on the vitest repo. So far I am able to write my mocks. I don't use vi.mock at all.

Something like this:

import MyClass from "path/to/MyClass.js"

describe( "Suite", () => {

  afterEach( () => {
    vi.restoreAllMocks()
  } )
  

  it( "test 1", async () => {
     vi.spyOn( MyClass.prototype, "getAll" ).mockResolvedValue( someDataHere );
     // some other code here to call the request
     expect()....
  } );


  it( "test 2", async () => {
     vi.spyOn( MyClass.prototype, "getAll" ).mockResolvedValue( someNewDataHere );
     // some other code here to call the request
     expect()....
  } );


} );

Now i can use watch mode consistently. I need to restart the command ocassionally as it's not picking up my changes sometimes.

Hope this works for you.

[emily-shen]

See #6918 for another reproduction of this issue.

[danawoodman]

I believe I'm noticing the same/similar behavior, but mine is a bit stranger: my tests pass in watch mode when I save the source file (src/index.ts) but fail when I save the test file (test/index.spec.ts)

The test failure in my case is saying Response.json is not defined:

Here is a minimal reproduction: https://github.com/danawoodman/vitest-pool-workers-mocking

In addition, in another (production) project I'm getting the exact same arbitrary failure when saving a test file vs the source file. It always seems as though the actual mocking does not occur in watch mode during a file save vs when saving the source file for some reason. So far, I've seen this issue 3 times and every time it was with vitest-pool-workers following the examples here: https://github.com/cloudflare/workers-sdk/blob/main/fixtures/vitest-pool-workers-examples

[eastlondoner]

I am also getting this issue when using import { defineWorkersConfig } from '@cloudflare/vitest-pool-workers/config';

[eastlondoner]

I think adding this fixes it

afterAll(() => {
  vi.clearAllMocks()
  vi.resetModules()
})