testTypeClassLaws will find the correct typeclass laws and test them. To define the tests required for the Option datatype, for example, we need to:

1. Provide a function to build an Equivalence<Option<A>> from an Equivalence<A>.
   • Thankfully, effect-ts has such a function in the Option module called getEquivalence.
2. Provide the same for arbitraries.
   • effect-ts-laws exports an option function. It takes an Arbitrary<A> and return an Arbitrary<Option<A>>.
3. List all instances for the datatype by their typeclass name.
   • Note in the code below some instances, for example Order, are built from the instance of the underlying type. The effect-ts-laws export monoOrder provides this for the Order typeclass.

The Option typeclass law test:

import {
  Alternative,
  Applicative,
  Foldable,
  getOptionalMonoid,
  Monad,
  Traversable
} from '@effect/typeclass/data/Option'
import {Option as OP} from 'effect'
import {monoEquivalence, monoOrder, monoSemigroup, option} from 'effect-ts-laws'
import {testTypeclassLaws} from 'effect-ts-laws/vitest'
import {OptionTypeLambda} from 'effect/Option'

describe('@effect/typeclass/data/Option', () => {
  testTypeclassLaws<OptionTypeLambda>({
    getEquivalence: OP.getEquivalence,
    getArbitrary: option,
  })({
    Alternative,
    Applicative,
    Equivalence: OP.getEquivalence(monoEquivalence),
    Foldable,
    Monad,
    Monoid: getOptionalMonoid(monoSemigroup),
    Order: OP.getOrder(monoOrder),
    Traversable,
  })
})
Copy

What do we get in return to our investment in the three steps above and in the added maintenance costs of this tiny, easy to maintain test?

Good coverage for a freight train full of fault models. Vitest reporter showing test results for the seventy one typeclass laws relevant to the effect-ts Option datatype as defined in the test above:

You wrote a new datatype: MyTuple, and an instance of the effect-ts Covariant typeclass. Lets test it for free:

import {Covariant as CO} from '@effect/typeclass'
import {Array as AR} from 'effect'
import {dual} from 'effect/Function'
import {TypeLambda} from 'effect/HKT'
import fc from 'fast-check'
import {testTypeclassLaws} from 'effect-ts-laws/vitest'

describe('MyTuple', () => {
  type MyTuple<A> = [A]

  interface MyTupleTypeLambda extends TypeLambda {
    readonly type: MyTuple<this['Target']>
  }

  const map: CO.Covariant<MyTupleTypeLambda>['map'] = dual(
    2,
    <A, B>([a]: MyTuple<A>, ab: (a: A) => B): MyTuple<B> => [ab(a)],
  )
  const Covariant: CO.Covariant<MyTupleTypeLambda> = {
    imap: CO.imap<MyTupleTypeLambda>(map),
    map,
  }

  testTypeclassLaws<MyTupleTypeLambda>({
    getEquivalence: AR.getEquivalence,
    getArbitrary: fc.tuple,
  })({Covariant})
})
Copy

fast-check will try to find a counterexample that breaks the laws. Because it is quite impossible to find one in this case you should see:

Above you see that eight typeclass laws that were tested:

1. Covariant identity and composition laws. count = 2
   1. Because Covariant extends Invariant, the typeclass laws of identity and composition of this typeclass are tested. count = 2 + 2
      1. effect-ts lets you compose a pair of Invariants into a new Invariant. There are fault models that will only be covered if we test such composed instances. To cover these fault models, the instance under test is composed with the Option Invariant instance and run through the identity and composition laws. count = 2 + 2 + 2
   2. effect-ts lets you compose Covariants as well. The instance under test is composed with the Option Covariant instance and run through the identity and composition laws. count = 2 + 2 + 2 + 2