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

Defer capturing original matchers #9

Closed
jcarlson opened this issue May 16, 2017 · 2 comments
Closed

Defer capturing original matchers #9

jcarlson opened this issue May 16, 2017 · 2 comments

Comments

@jcarlson
Copy link

Referring to this code snippet: https://github.com/PsychoLlama/expect-enzyme/blob/master/src/assertions.js#L120-L145

This creates a problem, because definitions for any original matchers are captured at the time this module is imported or required rather than at the time expect is extended. This can be problematic when used alongside app-specific matchers with colliding names.

For example, the following does not work:

// test/helpers/my-matchers.js
export function toHaveClass(className) { ... }
export function toNotHaveClass(className) { ... }

// test/setup.js
import expect from 'expect'
import myMatchers from './helpers/my-matchers'
import enzymeMatchers from 'expect-enzyme'

expect.extend(myMatchers)
expect.extend(enzymeMatchers)

In the above example, as soon as expect-enzyme is imported, it captures any existing matchers, but they haven't been extended onto expect yet. It is a syntax error to move the import statement for enzyme-expect lower in the file, as all import statements must be at the top.

This can be worked around using require syntax as follows:

// test/setup.js
import expect from 'expect'

const myMatchers = require('./helpers/my-matchers')
expect.extend(myMatchers)

const enzymeMatchers = require('expect-enzyme')
expect.extend(enzymeMatchers)

This second form allows expect to be extended with the app-specific matchers before requireing the expect-enzyme matchers. While this work-around is okay for my current use case, it might be more problematic if another module included enzyme-expect before the test setup module.

Just thought you'd like to know.

@PsychoLlama
Copy link
Owner

That's a good point @jcarlson, import statements usually go at the top. If people are using multiple extensions for expect, the assertion overloading won't work.

What if expect-enzyme exported a function instead?

import enzymeMatchers from 'expect-enzyme'
import customMatchers from './helpers/my-matchers'

expect.extend(customMatchers)
expect.extend(enzymeMatchers()) // invocation captures existing assertions

It wouldn't be able to see any extensions added afterwards, but it would solve the import dilemma.

PsychoLlama added a commit that referenced this issue May 28, 2017
If you import two assertion utilities and then later extend `expect`,
`expect-enzyme` won't see the existing assertions and will simply wipe
them out. Not ideal. This makes a breaking change: instead of exporting
an object, `expect-enzyme` exports a function. Calling that function
will capture the existing assertions and generate properly overloaded
assertions.

More details and discussion in issue #9
@PsychoLlama
Copy link
Owner

I've released v1.0 which exports a function. Instead of capturing the matchers on import, now it waits until it's invoked. That should help keep the import statements prettier 😉

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

No branches or pull requests

2 participants