Mock get, create, update, delete

[zirkelc]

I'm looking for a way to mock the get/create/update/delete function for testing. I think I actually have to mock the go function. Is there a way to mock only go or do I have to mock the get function to return a mocked go?

That is where I'm currently stuck with:

    const getMock = jest.spyOn(Tenant, 'get').mockImplementation(() => ({
      go: () => ({ data: tenant }),
    }));

[tywalch]

Though it is not typed (at the moment but this discussion item makes me think about it) there is a .go() method on the root of the entity. You could use that for the time being. I will say that until that is typed, it will be an unofficial API that is subject to change. It is possible I may change that soon though since it would make testing a lot easier

[zirkelc]

I also stumbled upon mocking go() but couldn't get the right return types for Jest. The problem with mocking only go() is that you don't know the operation (get, put, delete, ...) being executed, so it's difficult to return the right mock resolved value.

As a workaround, I created simple wrapper functions for getItem, putItem, etc., that I export and auto-mock with Jest. If I need a specific return value, I can import the specific function in my test case and set the mock implementation/value.

That works well, but creates a lot of boilerplate.

Maybe I should check the implementation of go() in detail to see if there is something I could use to distinguish the operation being currently executed.

[g-farrow]

I'm also having some problems in writing tests - I've been mocking the underlying dynamoDB doc client - but this requires detailed knowledge of the requests being made to DynamoDB, and these are abstracted by ElectroDB, so its very problematic.

Are there any examples of how mocking should be done when using Electro?

[ides15]

I've been using jest-dynalite and have been pretty happy with it so far. Instead of mocking your DynamoDB calls, jest-dynalite sets up one (or more) local in-memory DynamoDB-compatible* tables that you query against. You'll want to update your client that you use in your entities to point to the jest-dynalite tables:

/**
 * DynamoDB Client that all ElectroDB entities/services should use.
 */
export const client = new DynamoDBClient({
  region: process.env.AWS_REGION,
  // For use with jest-dynalite during testing
  ...(process.env.MOCK_DYNAMODB_ENDPOINT && {
    endpoint: process.env.MOCK_DYNAMODB_ENDPOINT,
    sslEnabled: false,
    region: "local",
  }),
});

Then in your tests, you can do something like:

describe("tests", () => {
  beforeEach(async () => {
    // Populate the table before the test
    await PersonEntity.create({
      id: "12345",
      name: "John"
    }).go()
  })

  it("returns a person", async () => {
    const { data } = await PersonEntity.get({
      id: "12345"
    }).go()

    expect(data).toBeTruthy()
  })
})

Setting up the tables is very fast - my project has ~450 tests, most of which involve setting up tables and querying against jest-dynalite. I use swc-jest as my test runner and the entire suite will run in about 30 sec.

Caveat - Dynalite doesn't currently support transactions, so I still have to mock my Service.transaction.write method, which is a pain.

* Dynalite is "an implementation of Amazon's DynamoDB built on LevelDB", so not actually using DynamoDB under the hood. But besides the transactions caveat noted above, I've had no issues with it.

[filipeestacio]

Just tried it out and this looks like the way forward. Thanks! Just one question, please. How are you testing for an error in creating an Item? Could you help with an example?

[ides15]

I've been using a spy on the DynamoDB client directly:

const clientSpy = jest.spyOn(client, "send");

// @ts-expect-error If the DynamoDB client fails for some unknown reason
clientSpy.mockRejectedValueOnce(new Error("Unable to create item"));

...

await expect(functionThatCreatesElectroDBEntity()).rejects.toBe("Unable to create item");

[zirkelc]

Just to add one more: I'm using LocalStack in combination with @testcontainers/localstack which allows you to start the container from the unit tests:

const container = await new LocalstackContainer().start();

I'm using it in another project for S3 buckets, but it should also work with DDB.