Vitest prop testing

[jessekelly881]

Adds property testing.

https://www.npmjs.com/package/@fast-check/vitest

import { Schema } from "effect"
import { it } from "@effect/vitest"

const realNumber = Schema.Finite.pipe(Schema.nonNaN())

it.prop("symmetry", [realNumber, realNumber], ([a, b]) => a + b === b + a)

it.effect.prop("symmetry", [realNumber, realNumber], ([a, b]) =>
  Effect.gen(function* () {
    yield* Effect.void
    return a + b === b + a
  })
)

it.scoped.prop(
  "should detect the substring",
  { a: Schema.String, b: Schema.String, c: Schema.String },
  ({ a, b, c }) =>
    Effect.gen(function* () {
      yield* Effect.scope
      return (a + b + c).includes(b)
    })
)

[changeset-bot]

🦋 Changeset detected

Latest commit: 8e2d386

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@effect/vitest	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mikearnaldi]

why not the following?

it.effect.prop("should detect the substring", { a: Schema.String, b: Schema.String, c: Schema.String }, ({ a, b, c }) =>
    Effect.gen(function*() {
      return (a + b + c).includes(b)
    })
)

[jessekelly881]

Yeah, I actually like that more. Updated.

[jessekelly881]

@mikearnaldi Mind having another look when you get the chance?

[mikearnaldi]

Looks good to me! I'll let @tim-smart and @gcanti comment / review

[tim-smart]

Whoops wrong PR. I'll review this one shortly.

[tim-smart]

Hmm we can't depend on /schema as it isn't part of the core package at this stage.

You can add it to a separate module however.

[jessekelly881]

Not even as a devDependency(for every other package besides /vitest)?

[tim-smart]

Not even as a devDependency(for every other package besides /vitest)?

It just can't be used in the /vitest/index.ts module, as /effect dogfoods it.

So you can add it as /vitest/PropertyTesting, but will lose out on the chainable api.

Or maybe it can extend the /index.ts apis in some way.

[jessekelly881]

I moved it to /Schema and went with prop.effect, prop.scoped, etc. for now. Hopefully that should do it.

[mikearnaldi]

Then I would say let's hold off until we merge schema

[jessekelly881]

Hmm. Well this is awkward.. jaja. I've updated it to hopefully fix the issue. Still think we should wait? What's the timeline for merging schema? If it's w/ 4.0 maybe it's worth merging this version and then updating the api once schema is merged?

[mikearnaldi]

Hmm. Well this is awkward.. jaja. I've updated it to hopefully fix the issue. Still think we should wait? What's the timeline for merging schema? If it's w/ 4.0 maybe it's worth merging this version and then updating the api once schema is merged?

Merging schema is not a breaking change for effect so most likely a matter or weeks

[jessekelly881]

Gotcha. Makes sense to revert to the original version and wait then. I'll ping this again when Schema gets merged.

[jessekelly881]

@tim-smart @mikearnaldi I rebased this against next-minor w/ schema merged into effect. Mind having another look?

[tim-smart]

Don't think you need any generics here. Also I don't think you can assign Schema.Never to this.

[jessekelly881]

Arbitrary doesn't support Schema.Never so I think not being able to assign Schema.Never to it is fine. But, yeah, this can be Schema.Any w/o the generics

effect/packages/schema/src/Arbitrary.ts

Lines 154 to 157 in b836fc4

	case "NeverKeyword":
	return () => {
	throw new Error(errors_.getArbitraryUnsupportedErrorMessage(path, ast))
	}

[tim-smart]

Just need to rebase this again.

[jessekelly881]

Done :)

[tim-smart]

Done :)

Rebase, not merge, as there are a bunch of duplicate commits atm.

[jessekelly881]

There we go. Had to do some serious git magic to make that work jaja.