Open purplecabbage opened 4 years ago
We have numerous instances of global.expect...
// eslint-disable-next-line jest/expect-expect test('when path is not a valid string', async () => { await global.expectToThrowBadArg(files.delete.bind(files, 123), ['filePath', 'string'], { filePath: 123, options: {} }) })
This means, we need to have many, many eslint-disable-next-line jest/expect-expect
eslint-disable-next-line jest/expect-expect
A better practice, and the jest recommended way is to define our own expect extensions
expect.extend({ toThrowBadArg: ( words, options ) => { // more expectations here ... } }) // then tests call it like this: expect(files.delete.bind(files, 123)).toThrowBadArg( ['filePath', 'string'], { filePath: 123, options: {} })
If we do this well, they can be reused across multiple repo/libs
jest example here: https://jestjs.io/docs/en/expect#expectextendmatchers
JIRA issue created: https://jira.corp.adobe.com/browse/ACNA-938
We have numerous instances of global.expect...
This means, we need to have many, many
eslint-disable-next-line jest/expect-expect
A better practice, and the jest recommended way is to define our own expect extensions
If we do this well, they can be reused across multiple repo/libs