Correct way to test laws.

Hello fantasy crew!

I’m wondering, what is the “correct” way to ensure that a custom data type is lawful?

My initial thought was to include modules from the /laws directory and define a custom eq method.

Here is an example for an IO implementation conforming to Functor (using jest, if you’re interested)

const VAL = 1;
const eq = (a, b) =>
  a.run() === b.run();

test('Functor', () => {
  const identity = functor.identity(IO.of)(eq)(VAL);
  const composition =
    functor.composition(IO.of)(eq)(add(1))(multiply(10))(VAL);

  expect(identity).toBe(true);
  expect(composition).toBe(true);
});

This was going quite well until I tried to write a test for Foldable. It seems that the test for Foldable depends on a toArray method that isn’t mentioned anywhere in the spec. This leads me to believe that the the checks defined in /laws are more guidelines for writing tests, instead of being the tests themselves.

I was hoping someone could provide some clarification. I would love to be able to prove in tests that implementations are law-abiding for any given version of FL.

[davidchambers]

That depends on your use case, @dustinws. It’s probably a good idea to point to a commit hash rather than the branch name as I’ll delete the branch once the pull request has been merged. GitHub never seems to garbage collect dangling commits, so even if I rebase you should be able to continue to access the existing commits by their hashes.

[davidchambers]

@dustinws, have a look at fantasyland/fantasy-laws#1. The code is complete, but I’d like to improve the readme before merging the pull request. Please share any thoughts that occur to you. 😃