Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide global parameters definition #402

Closed
BourgoisMickael opened this issue Aug 17, 2019 · 2 comments · Fixed by #439
Closed

Provide global parameters definition #402

BourgoisMickael opened this issue Aug 17, 2019 · 2 comments · Fixed by #439

Comments

@BourgoisMickael
Copy link

BourgoisMickael commented Aug 17, 2019

🚀 Feature Request

Provide a way to define parameters on fc rather than defining them in each fc.check or fc.assert.

Motivation

I'm using the same parameter { verbose: true } for each call of fc.check and I'd like to provide it only once for all my tests

Example

fc.setParameter({ verbose: true })

fc.assert(
  fc.property(
    fc.integer(), num => { throw new Error(num) }
  ),
  // { verbose: true } No need to define the parameter here
)

Right now to achieve this behavior, I'm doing something like this:

  const fcCheck = fc.check
  const fcAssert = fc.assert

  function wrapCheck (property, param = { verbose: true }) {
    return fcCheck(property, param)
  }

  function wrapAssert (property, param = { verbose: true }) {
    fcAssert(property, param)
  }

  fc.check = wrapCheck
  fc.assert = wrapAssert
@BourgoisMickael BourgoisMickael changed the title Provide global parameter Provide global parameters definition Aug 17, 2019
@dubzzz
Copy link
Owner

dubzzz commented Aug 18, 2019

There is definitely a need for such feature. When I first though about this kind of feature I opened #65.

Your suggestion is a bit different as it suggests to put the configuration in the code itself (instead of env in the other issue) but in a way they both fulfill the same need.

The only blocking point I see with such is that it makes the behaviour of fc.assert and fc.check dependant of its execution context.

  • What would be the behaviour of?
fc.setParameters({ verbose: 1 })
fc.assert(fc.property(fc.boolean(), b => true), { seed: 42 })
// do we consider { seed: 42 } or { seed: 42, verbose: 1 }?
// IMO the second one seems better
  • Do we allow to set anything with fc.setParameters or only a subset?
    For instance: replayPath is very specific to one fc.assert while seed, numRuns or verbose can be set globally.

  • How do we make the user knowledgeable that her fc.assert settings have been tweaked by a global configuration? Do we make the user aware of the fact that we took the configuration from a global?

Before implementing such I'll need to check how other big libraries or test frameworks deal with such global configurations that can be set both at test level and global level.

@dubzzz
Copy link
Owner

dubzzz commented Oct 6, 2019

@BourgoisMickael I just worked a bit on this feature request, see #439

After that commit a code like:

test('test #1', () => {
  fc.assert(
    myProp1,
    { numRuns: 10 }
  )
})
test('test #2', () => {
  fc.assert(
    myProp2,
    { numRuns: 10 } // duplicated
  )
})
test('test #3', () => {
  fc.assert(
    myProp3,
    { numRuns: 10 } // duplicated
  )
})

Can be written:

fc.configureGlobal({ numRuns: 10 })
test('test #1', () => {
  fc.assert(myProp1)
})
test('test #2', () => {
  fc.assert(myProp2)
})
test('test #3', () => {
  fc.assert(myProp3)
})

In the case of Jest test runner, the call to configureGlobal can be extracted into setupFiles option of Jest so that it will apply to all specs.

With this PR I add three main functions (the first one is certainly the most important one):

  • fc.configureGlobal(parameters: Parameters): define the default parameters to be used by runners
  • fc.resetConfigureGlobal(): reset the default parameters to be used by runners
  • fc.readConfigureGlobal(): output the default parameters to be used by runners

What do you think of this feature? Naming, usage...?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants