RFC: Mocking

[colinhacks]

I'm open to a PR for a .mock method that lets you generate mock data for your schemas.

Proposal

New base method: .mock

A .mock method on the base class.

z.string().mock(); // => "AkvoFxGfoHFhdfKF" (random string)
z.number().mock(); // => 18916.19016 (random number)

Overrides

This method could accept some parameters that let you overriding the default mocking functions for each data type (e.g. strings, numbers, tuples, etc).

z.string().mock({
  stringMocker: ()=>['hello', 'goodbye'][Math.round(Math.random())]
});
// => randomly chooses "hello" or "goodbye"

Instance-specific mocking functions

There would also need to be a way to override the mocking function for a particular schema instance (probably a .mocker() or .setMocker() method on the base class).

z.string()
  .refine(val => val === val.toLowerCase())
  .mocker(()=>{
    return randomString().toLowerCase();
  })
  .mock(); // => "akvofxgfohfhdfkf"

Issues

Refinements

Zod has no way of generating a value that satisfies a given refinement. There would also need to be a way to override the mocking function for a particular schema instance (probably a .mocker() or .setMocker() method on the base class).

Unions

Which union "option" should be used to generate the value? Perhaps a randomly chosen one? Should the mocked value for an optional value be undefined 50% of the time?

Transformers

Should Zod mock a value for the input or the output type? Not a huge issue, this can just be an option/flag in the .mock method.

[lo1tuma]

My thoughts on this topic:

• Since zod is already quite big in terms of bundle-size without support for tree-shaking, I think this should be a separate package or at least a separate file that is not loaded when doing import * as z from 'zod'.
• I prefer static data over random dynamic data in order to implement reproducible tests. My go-to library here is cooky-cutter which allows you to define factories where you can partially override the default values. This makes it easy to write small test that focus only on some specific properties of an object. Maybe it would be possible to automatically create such factories from a zod schema.

[colinhacks]

I'm inclined to disagree. This would add maybe a kilobyte to the bundle size max. Plus I consider mocking is a pretty fundamental bit of functionality for a library that is trying to be the single-source of truth for type information.

Pretty sure we could eliminate more than a kilobyte from the bundle by using the removeComments option in tsc...just realized I haven't enabled that 😬

[o-alexandrov]

Based on the same building/bundling-related reasons from #264 (comment)
Please kindly consider to add this feature as a separate utility function

[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.