Allow for separate config file

[lmiller1990]

What problem does this feature solve?

I work in a non English speaking country, so we are using vue-i18n to create a bilingual app. It adds a global $t function. I have to do:

mocks: {
  $t: jest.fn()
}

in every test, or the test fails with $t is undefined, since almost all components have some form of text.

Other users have a similar use case to mock regularly occurring global objects. More comments in this thread: #325

What does the proposed API look like?

I still think a config file would be good. I'm thinking something along the lines of a test-utils.config.js that could be something like this:

export default {
  mocks: {
    // mocks to use in all tests
    // they should be merged with any mocks passed in `shallow` or `mount`
    // the ones from `shallow`, `mount` should take priority and override the ones in this config file
  },
  stubs: {
    /* I often find myself wanting to stub certain components a lot as well */
  }
}

You should be able to provide defaults for anything you can pass in the options object to shallow and mount.

vue-test-utils shouls look for a default config file in the root directory (for example test-utils.config.js).

[eddyerburgh]

We currently have a global config object. We could merge the two, with the inline config taking precedence over the file.

Would you like to make a PR adding this feature?

[38elements]

What are the benefits of supporting configuration files?
I think it is possible to use the require option of Mocha and set a value to VueTestUtils.config.

[lmiller1990]

I think the value of a config file is that vue-test-utils can handle the config, as opposed to leaving it up to the user and their choice of test runner.

Another solution would be allow the config to set all options (right now it only supports stubs, I think), and leave the rest up to the user. I personally like the idea of letting vue-test-utils look for a default config.js file.

[eddyerburgh]

We should definitely support all options in the config object, regardless of whether we support a config file or not.

[lmiller1990]

Agreed. I'll make a PR for #325 in an hour or so (just writing the tests now) for supporting mocks, but if it's generic enough supporting the rest of the options in the same manner should be straightforward.

[38elements]

Thank you for replying.

IMHO,
Since it is not necessary to use multiple test runners for same test,
I think that not depending test runner does not become benefit.
Adding a function is adding maintenance cost and complex.
I think if the function provided by a test runner resolve it, it is not necessary to adding this function.

Supporting all options in the config object is other issue.

[eddyerburgh]

I agree with @38elements, adding an extra config file adds a lot of work on our end. Since we already have a config object, all the setup can be done in there.

I'm closing this as something we aren't going to implement.