• start with create a user, generate random ID and generate createdAt. How do we mock these dependencies? Introduce the idea of dependency injection. Then introduce the idea that Imports are dependencies so rather than calling new Date() directly, we could call getCurrentTime() which does this on our behalf. But the point is to A) make the dependency explicit and B) make it easier to mock / test.

• The other approach is rather than mocking these values, make your tests do expect.any(String). There’s tradeoffs, I would say I would rather have consistency with mocked values rather than looser assertions with uncontrolled inputs.

• Sometimes we create our aws sdk clients in the same file as our repository, which means we need to come up with inventive ways to mock the clients. Maybe use spyOn

• we use a lot of packages

• Typically, packages come with a set of opinions on how to write your application. Usually you don’t want to give them too much control because packages change. The underlining message is that software changes rapidly.

• Building an interface over a package can be useful for abstracting away annoying implementation details. You can plug in and play with packages that have the same functionality

• When we write applications, sometimes we find it difficult to test. Sometimes this is because of the way we have written our application and sometimes it’s because of the API that a package exposes. Can we avoid having an

• What do we want at the end of the day? We want confidence in our application. We want confidence so that we can deliver value faster.

• it’s insane to me that the answer to having poor test ability is to introduce another package. Not only one but TWO packages because the jest matcher package solves the problem of having poor ways to check what the mock client was called with

• Introducing a new package introduces a few problems including needing to upskill developers on yet another way to test, along with associated best practises.

• If you have ever run into the dreaded AWS SDK types conflicts then you’ll know the pain of resolving that bc you have to reconcile the mock library types with the AWS SDK types

• But, aws-sdk-client-mock actually comes with really nice types! Is there a way to do this with native jest? Yes there is

• This can also help with migrating between AWS SDK v2 to v3 because your interface is the same except for the imports of the types

• What about the client that comes with all of the service methods? Yep you can definitely use that as well. The typing is a bit jank so it is probably good to introduce an interface anyway to reduce repetitive type assertions

Key takeaways

Big picture

• Having an interface is a common pattern for abstracting specific implementation details and making your application more resilient to the underlying implementations. Common use cases for this pattern are HTTP Clients and loggers
• How you write your application code affects how testable your application code is. While it is usually possible to use fancy mocking to wrangle your test, sometimes it is easier to restructure your application or introduce an interface to make it easier to test
• Be conscious about the tradeoffs of following the opinions that a library has

Small details

• Use jest.mocked / vi.mocked for type inference for your mocks and greater type safety
• Provide types for assertions like toEqual and toHaveBeenCalledWith.
• You can use Parameters<typeof FUNCTION> and Awaited<ReturnType<typeof FUNCTION>> if you don't want to maintain separate types for your function signatures.