Mocking high-level interfaces

[jalmonter]

Let's review the (proposed) best practice below and brainstorm ways to implement it effectively in our spec files:

• Mock High-Level Interfaces: When testing interactions with dependencies like databases or external services, mock the high-level methods or interfaces your worker uses (e.g., createUser, fetchData, sendEmail). This keeps tests focused on the worker's behavior without tying them to specific implementation details.

At a minimum, these high-level interfaces must:

• Be spied on, to determine if they were called and with what parameters.
• Be exported from the main index.ts file generated by wall-e.

Attempts so far

I wrote this spec file in this PR. The issue with this approach is that the exported functions can't be reused in the index.ts file generated by wall-e. It would need to decouple these functions from the index.ts file and move them into a separate file.

@1712n/dni-nlp-backend

[jalmonter]

Dynamic Module Re-Import

I'm trying to re-import the index module dynamically (after mocking) like so:

vi.mock("./../src/index", () => ({
  getOrCreateUniqueMessage: vi
    .fn()
    .mockImplementation(
      async (
        db: NodePgDatabase<Record<string, never>>,
        data: { content: string }[]
      ) => {
        return Promise.resolve(uniqueMessages);
      }
    ),
  createMessageFeed: vi
    .fn()
    .mockImplementation(
      async (
        db: NodePgDatabase<Record<string, never>>,
        data: { [key: string]: any }[]
      ) => {
        return Promise.resolve([]);
      }
    ),
}));

it("should insert valid messages into the database", async () => {
  const { getOrCreateUniqueMessage, createMessageFeed } = await import(
    "./../src/index"
  );

  await SELF.scheduled();

  expect(getOrCreateUniqueMessage).toHaveBeenCalledOnce();
});    

The getOrCreateUniqueMessage function appears to be "called," and vitest identifies it as a spy, but it is not actually invoked:

AssertionError: expected "spy" to be called 1 times, but got 0 times

I'll keep looking into it.

[jalmonter]

I've spent more time trying to mock high-level functions, but it's impossible without moving them to a separate file. Keeping all the code in one module makes testing really difficult and is considered bad practice. I think we should focus on making testing easier in some other way.