Mocking

[dipasqualew]

Hi,

I have started working on a zod-generators companion library with aim of generate random values, both valid or invalid, given a zod field of any type.

As a middle ground between functional and unit testing, I often write fixtures for my models, specifically for messages (HTTP request bodies, queue messages). Since the model is shared between producer & consumer, I can write contractual tests as the generated fixtures are shared. I then test that my producer spits out a valid value, and then I check that the consumer is able to process my generated fixtures.

The idea here is to generate fixtures and more importantly random fixtures easier to generate. For example, if my model defines a string and a number, then I would have a function to generate permutations of what can be valid and what can't be valid.

I think the only issues we would see here is with refines (I think we can just apply transforms to the valid generated values) as they are business logic that we can't dynamically inspect.

I have a PoC with very basic support for zod.boolean, zod.number and zod.string here:
https://github.com/dipasqualew/zod-generators

I was just curious of your thoughts before I put more effort into this 🙂

Cheers

[colinhacks]

I think it's a good idea! I considered putting something similar in the core library but decided against it: #197. I think there's a definite need for something like this. I'd definitely link to it in the README.

I think "mocking" would be a more recognizable term for this. My first thought when I saw the title of this issue was of JavaScript generators. Maybe try to get the zod-mock NPM module if it's available.

Refinements are definitely tricky. The easiest thing is just to ignore refinements for now.

I agree, transforms shouldn't be an issue.

Note that as of alpha.7, things like z.string().email() are no longer implemented internally as refinements. So you can easily check if a string schema should be an email address like this.

const isEmail = !!z.string().email()._def.isEmail;

Perhaps I could potentially let users optionally specify a mocking function when they define a refinement.

z.string().refine(val => val === val.toUpperCase(), { 
  mock: makeRandomString().toUpperCase()
});

Then your library could check for the existence of mock on the refinement object. Generating invalid mock data would be tricker.

Keep me posted!

[dipasqualew]

Good feedback, thanks mate!

I think you are right about the lib name, so I renamed the repo to zod-mocking:
https://github.com/dipasqualew/zod-mocking

Still in the Proof of Concept state but I proved that we can generate mocks of arbitrary depth via zod.object and zod.array. Thanks for the work you did on the API, it was really straightforward to read the field definition in _def.

I really like the idea of having a mock metadata key that could be used to override an automatically generated mock.

I am going to use the library on some pet project for a while and report back on its state.

Unrelated question:

I think zod is going to seriously compete against yup as it is TypeScript first and it has a couple of killer features like zod.infer and zod.object().omit().

Do you plan to move this repo into a zod organisation? (i.e. https://github.com/zod-models or something, as zod is already taken). That would be the natural place for other supporting libraries could live after their trial and once they are production ready

Unfortunately zod is also taken on NPM (https://www.npmjs.com/org/zod, unless that's you?) but that would also help with packaging.

[colinhacks]

I wasn't really planning to put Zod into a GitHub org. I also don't own the zod org on NPM. Let's just start with zod-mocking for now (I like the look of that better than @zod-schema/mocking anyway), and if more libraries start popping up in the Zod ecosystem we can consider moving everything into an NPM org.

[colinhacks]

I'm planning to add an "Ecosystem" section to the README so I can link to stuff like this. What's the status of the project? If you throw together a README describing the how to use it and which types are currently supported, then I'll happily add you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.