aws-sdk-client-mock VS fast-check

If you are using the AWS JS SDK v3, the best way to mock it for unit tests is to use the aws-sdk-client-mock library.

This does not mean we never used aws-sdk-mock - haven't tried yet this version for SDK v3 - check this article for more info - but in general I try to write very simple unit tests, and very simple integration tests, keeping mocks to a minimum.

Libraries like JSVerify or Fast-Check offer essential tools to facilitate property-based testing.

Strong agree!

For JavaScript, I suggest folks check out fast-check [0] and this introduction to property-based testing that uses fast-check [1].

This is broadly useful, but one specific place I've found it helpful was to check redux reducers against generated lists of actions to find unchecked edge cases and data assumptions.

[0] https://github.com/dubzzz/fast-check

Brilliant, this is a massive improvement. Previously I was fumbling around in https://github.com/dubzzz/fast-check/tree/main/packages/fast-check/documentation for info.

There's a library for exactly that: FastCheck.

It makes @fast-check/jest, the best option to integrate Jest and fast-check, as it provides an abstraction over both to ease their mutual integration.

The closest that I know of (and I have not used this) is zod-fast-check. It generates fast-check “arbitraries” (test data generators) for property-based testing based on zod schemas. Of course, this requires that you use zod to define your types, which has some downsides. Fortunately there is another tool, ts-to-zod, (which I also have not used) which will codegen zod schemas based on TS type definitions. If you thread these four libraries together you should end up with the ability to write random tests on generated data with very little overhead. In theory.

For something like this, I might break out fast-check for testing. It’s good at generating a wide range of values for a given type, and could help you get good test coverage without having to hand-author a lot of repetitive error inputs.