Feat: allow access to the Durable Object's instance from inside a test

[cdrx]

cdaa62b added the ability to directly construct a Durable Object, which is great for testing a DO in isolation but doesn't allow for easily testing Durable Objects that communicate with other Durable Objects.

Without access to the internal instance that stub.fetch(...) uses, it isn't easy to test request that span across multiple Durable Objects.

For example, given this example of an object that makes a sub request to another object:

class TestObject extends DurableObject {
  fetch(request) {
    // make a subrequest to OtherObject
    const { OTHER_OBJECT } = getMiniflareBindings();
    const id = OTHER_OBJECT.idFromName("test");
    const stub = OTHER_OBJECT.get(id);
    return stub.fetch("https://object/");
  }
}

class OtherObject extends DurableObject {
  testFunction() {
    return "Hello world"
  }
  
  fetch(request) {
    return new Response(this.testFunction());
  }
}

The change in this PR allows writing a test that can introspect the behaviour of OtherObject, even though the initial request goes to TestObject, like this:

test("", async () => {
  const { TEST_OBJECT, OTHER_OBJECT } = getMiniflareBindings();
  
  const otherId = OTHER_OBJECT.idFromName("test");
  const otherInstance = getMiniflareDurableObjectInstance(otherId);
  const otherTestFunction = vi.spyOn(otherInstance, "testFunction");
  
  const testId = TEST_OBJECT.idFromName("test");
  await TEST_OBJECT.get(testId).fetch("https://object/");
  
  expect(otherTestFunction).toHaveBeenCalledOnce();
});

[cdrx]

@mrbbot I'm curious about how the architecture will look, when using Miniflare with the OSS runtime.

When running tests, will it be the case that the Durable Object are run inside the OSS runtime (V8), but Miniflare still runs Jest inside Node's JS context?

[mrbbot]

Hey! 👋 Thanks for raising this use case, and opening the PR! 🙂 I've added a comment about input/output gating. Interested to hear your thoughts, but otherwise happy to merge this. ✅

[mrbbot]

The problem here, is that fetch won't run under the input/output gates, so concurrent calls to fetch may produce invalid results. I'm not too sure what the best solution here is:

1. We could ask users to also do const state = getMiniflareDurableObjectState(), and use runWithMiniflareDurableObjectGates() as above, but reflecting on that API now, it feels a little too verbose.
2. We could wrap use a Proxy or something on getMiniflareDurableObjectInstance() to intercept fetch() calls and apply input/output gates to them, but this might break mocks/spies.

Maybe option 1. is fine for now. What do you think?

[mrbbot]

I'm curious about how the architecture will look

Me too! 😉 We're discussing this internally. It should be possible to use a custom Jest runner which runs tests out-of-band in workerd. This would tie us to Jest, which I'd rather not do. Alternatively, we could try compile workerd to a Node native module including Workers runtime APIs, and do things like we're doing at the moment injecting them into the global scope.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 75cffa3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR