Jest Fast Check doesn't allow zero arbitraries

[CMCDragonkai]

🐛 Bug Report

I wrote a test like this:

  testProp.only(
    'import and export',
    [],
    async () => {
      const keyPair = await generate.generateKeyPair();
      const cryptoKeyPair = await asymmetric.importKeyPair(keyPair);
      expect(cryptoKeyPair.publicKey.type).toBe('public');
      expect(cryptoKeyPair.publicKey.extractable).toBe(true);
      expect(cryptoKeyPair.privateKey.type).toBe('private');
      expect(cryptoKeyPair.privateKey.extractable).toBe(true);
      const keyPair_ = await asymmetric.exportKeyPair(cryptoKeyPair);
      expect(keyPair_.publicKey).toStrictEqual(keyPair.publicKey);
      expect(keyPair_.privateKey).toStrictEqual(keyPair.privateKey);
      return true;
    },
    { numRuns: 100 }
  );

It ends up throwing this:

  ● keys/utils/asymmetric › import and export (with seed=1663912665057)

    asyncProperty expects at least two parameters

      at Object.asyncProperty (node_modules/fast-check/lib/check/property/AsyncProperty.js:10:15)
      at Object.<anonymous> (node_modules/@fast-check/jest/lib/jest-fast-check.js:16:28)

But if I give it 1 arbitrary, then it works like:

  testProp.only(
    'import and export',
    [
      fc.integer()
    ],
    async (i) => {
      const keyPair = await generate.generateKeyPair();
      const cryptoKeyPair = await asymmetric.importKeyPair(keyPair);
      expect(cryptoKeyPair.publicKey.type).toBe('public');
      expect(cryptoKeyPair.publicKey.extractable).toBe(true);
      expect(cryptoKeyPair.privateKey.type).toBe('private');
      expect(cryptoKeyPair.privateKey.extractable).toBe(true);
      const keyPair_ = await asymmetric.exportKeyPair(cryptoKeyPair);
      expect(keyPair_.publicKey).toStrictEqual(keyPair.publicKey);
      expect(keyPair_.privateKey).toStrictEqual(keyPair.privateKey);
      return true;
    },
    { numRuns: 100 }
  );

It appears that the jest fast check doesn't work when there are no arbitraries to use.

Why do I want this? Well because I just want it to run multiple times and allow me to generate random things within the predicate itself.

To Reproduce

Try it in a jest test runner.

Expected behavior

That it should work with no arbitraries... in fact it would be great if it didn't require the [] at all and just take the async function directly.

Your environment

Packages / Softwares	Version(s)
fast-check	3.0.1
node	16.17.0
TypeScript*	4.7.4

*Only for TypeScript's users

[CMCDragonkai]

Actually I just realised this is the case for fc.asyncProperty in general. So it's not actually possible to use fc without at least 1 arbitrary?

[CMCDragonkai]

Was confused because the testProp allows this to be the case by fc.asyncProperty does not.

[dubzzz]

Actually not passing any arbitrary to the property (or empty array case in @fast-check/jest) is prohibited in fast-check as it does not need to be a property based test.

Indeed in order to be efficient property based tests need not only to generate random entries but also to generate them the right way (in a seeded way). More precisely anything dealing with non-deterministic stuff close to random has to be handled via an arbitrary either home made, derived from existing (through map, filter...) or directly built-in. Meanwhile you use fast-check to build you a seed that will be use to feed an internal random generator declared within your predicate as shown in https://github.com/dubzzz/fast-check/blob/296cde419382eac6fe257ac4105a893dbdf5cfcc/packages/fast-check/documentation/Tips.md#combine-with-other-faker-or-random-generator-libraries.

In a nutshell: the random part of the random generator has to be done within an arbitrary, otherwise relying on a simple loop is the same.

[dubzzz]

Side note: neither itProp, nor testProp should accept no arbitraries, signature of testProp should be fixed.

[CMCDragonkai]

Hmm the only issue is that webcrypto API doesn't provide any seeding capability for their CSPRNG...

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

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