[TEST]: add tests for api handlers

[slackermorris]

Yup. I think a lot will fall out from this. I'm getting the feeling that the backend is a little convoluted.

[slackermorris]

OK. I just added Zod. The lambda typings are a dogs breakfast so I need to figure how I can make sense of it all.

There is also this helpful article for mocking underlying AWS services: https://aws.amazon.com/blogs/developer/mocking-modular-aws-sdk-for-javascript-v3-in-unit-tests/

[slackermorris]

Maybe it is better to declare schemas for the different entities in my DB. Sort of like:

const userSchema = new Schema({
  fullName: {
    type: Schema.Types.String,
    required: true,
    unique: true,
  },
  email: {
    type: Schema.Types.String,
    required: true,
    unique: true,
  },
  password: {
    type: Schema.Types.String,
    required: true,
  },
  birthDate: {
    type: Schema.Types.Date,
    required: true,
  }
}, {
  collection: "users",
  timestamps: true,
});

[slackermorris]

This is a really helpful article on Zod and TypeScript and the difference. Worthwhile read.

• https://kaliex.co/boosting-type-safety-productivity-with-zod-typescript/

[slackermorris]

Middy middleware example: https://socket.dev/npm/package/middy-kneel-before-zod

[slackermorris]

OK I fixed the signature for the handler wrapper types. Now I have the issue of the pathParameters conflicting.

[slackermorris]

This is the issue I am facing:

type UndefinedPathParameters = {

  pathParameters?: undefined;
};

type Boo = UndefinedPathParameters & z.infer<typeof eventSchema>;

const apple: Boo = {
  pathParameters: {
    username: "joe",
  },
};

Interestingly enough, the expected fix with Omit works:

type Boo = Omit<UndefinedPathParameters, "pathParameters"> &
  z.infer<typeof eventSchema>;

So, why doesn't it work with the AWS types?

[slackermorris]

This is the issue I am now having w/r/t the ApiHandler and the typing of the event: https://github.com/microsoft/TypeScript/issues/50027

[slackermorris]

Not exactly what I am after but it does serve as a good example of at least... something.

• https://www.youtube.com/watch?v=b6p25GzGsAE

[slackermorris]

Well, I just found out why Ed chooses to take this approach:

https://stackoverflow.com/questions/69769503/how-can-i-use-typescript-partials-to-test-aws-lambda

[slackermorris]

I want to express that the Event is in fact an API Gateway Proxy Event.

[slackermorris]

Sweet. I set up a custom Zod Error mapper. I just need to confirm that I get the message back from the error handler.

[slackermorris]

So, I am using Walters' write up for testing Dynamo to try and test my own endpoints. The issue is that I am unsure what version of the aws-sdk I am using.

[slackermorris]

I should read this to understand the difference between aws-sdk V2 and V3: https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/welcome.html#welcome_whats_new_v3

[slackermorris]

I feel like I am just going to have to bite the bullet and introduce aws-sdk V3 because the testing utilities depend on it.

[slackermorris]

This is a really helpful resource to understand the difference between @aws-sdk/dynamo client and lib: https://medium.com/@phillip.le/unit-testing-aws-sdk-in-typescript-236df2d73332

[slackermorris]

Here is someone raising a concern about sst not supporting V3: https://forum.serverless.com/t/support-for-nodejs18-x-and-aws-sdk-v3/18399

Another example of someone wondering about this: https://github.com/serverless/serverless/issues/11920

It doesn't seem as though they intend to support V3?

[slackermorris]

It seems as though you can use the V3 sdk without requiring an equivalent migration by sst. I'll need to write this up to understand this.

[slackermorris]

I need to read this about transitive and direct dependencies: https://fossa.com/blog/direct-dependencies-vs-transitive-dependencies/

[slackermorris]

dynamoDbRepository is a good example of migrating to V3.

[slackermorris]

Give a good read of this tomorrow morning: https://aws.amazon.com/blogs/developer/mocking-modular-aws-sdk-for-javascript-v3-in-unit-tests/

[slackermorris]

So, if I want to mock out V2, then I'll need to follow a pattern something like:

const mockDynamoPut = jest.fn();
jest.mock('aws-sdk/clients/dynamodb', () => ({
  DocumentClient: class MockDocumentClient {
    put(...args: Array<unknown>) {
      return {
        promise: () => mockDynamoPut(...args),
      };
    }
  },
}));

    expect(mockDynamoPut).toHaveBeenCalledWith(
      expect.objectContaining({
        Item: expect.objectContaining({
          accountId: mockAccountId,
          data: mockChecklistDefintionOverrides,
          meta: expect.objectContaining({ userId: mockUserId }),
        }),
      })
    );

Which is fine, but when I upgrade to V3 then the whole approach will need to be refactored. I think it is better that I upgrade to V3 now.

[slackermorris]

Cool. I have written the getUser test.

[slackermorris]

I think I will write the createUser test now.

[slackermorris]

Lol I forgot that I did a tonne of refactoring of everything to make this happen.

[slackermorris]

I need an http JSON body parser. I think this means I need to install middy.

[slackermorris]

OK I added middy middleware. I actually think I could have done it myself, but meh. It is handier than doing that me thinks.

[slackermorris]

Endpoints create and get user both work now and are unit tested.