Why does fast-check expect a boolean return value rather than using errors like jest & co?

[jasikpark]

Most testing frameworks use expect and whatnot to detect success / failure

Does

// for all a, b, c strings
// b is a substring of a + b + c
testProp(
  'should detect the substring',
  [fc.string(), fc.string(), fc.string()],
  (a, b, c) => {
    expect((a + b + c).includes(b)).toBeTrue()
  },
)

or

import {formatDate} from '../misc'
import {testProp, fc} from '@fast-check/jest'

testProp(
  'formatDate formats the date to look nice',
  [fc.date({min: new Date('1950'), max: new Date('2050')})],
  d => {
    const parsedDate = new Date(formatDate(d))
    const parsedAndNotAreSame =
      parsedDate.getFullYear() === d.getFullYear() &&
      parsedDate.getMonth() === d.getMonth()
    if (!parsedAndNotAreSame) {
      console.log({initialDate: d, formattedDate: formatDate(d), parsedDate})
    }
    expect(d).toBe(parsedDate)
  },
  {verbose: true},
)

^^ this is not an amazing property test I've figured out, since formatDate returns Jan 88 for January 31st, 1988, so it's not too possible to do a print/parse property test over it

I might be ignorant and maybe fast-check succeeds if void is returned and fails if an error is thrown like jest & company?

[dubzzz]

Boolean value returns has been there to be aligned with the API provided by jsverify (another PBT framework for JS). The recommendation is to go for expect but both returning boolean or void works so for some very concise cases returning boolean values can just be seen as a very short way to write the property.

[jasikpark]

Ah, ok! I think I'll investigate further then, I'm really appreciating the jest/ava integration efforts -- I'll try to use those to make property tests look just a bit more like unit tests - part of my interest in allowing expect v.s. a manual boolean check