Use Enzyme for Integration Testing (end-to-end testing)

lelandrichardson commented 8 years ago

Several people have reached out to me regarding integration testing with Enzyme. While Enzyme is currently intended only for "Unit" Testing, I think that there is significant value to be extracted from Enzyme's API that could be used in the context of an integration test.

I'm not sure what this looks like yet. We could integrate with another (mature) integration testing framework, or we could build one ourselves and include it in this project, or we could build another project that depends on enzyme, or {insert your idea here}.

I'm creating this issue as an initial discussion grounds for people that are interested in this, and would like to discuss or propose ideas.

ljharb commented 8 years ago

Anything using mount is already an integration test - since "integration test" has lots of meanings, can you clarify what this means in the context of enyzme?

lelandrichardson commented 8 years ago

@ljharb what I mean is something closer to selenium / capybara.

Essentially, there could be a way that you point your test driver to a web-based endpoint that tests your full stack, and then you get a page with 0-many react root nodes (running along with any other JS you're including on the page). You'd be able to utilize enzyme or an enzyme-like API to target specific nodes/components on the page, and execute more complex behaviors (such as authenticating through an API, etc).

CrshOverride commented 8 years ago

It doesn't look like there's much activity here. I actually just started evaluating enzyme for integration testing. I've successfully rendered our application by mounting the top-level component along, our Redux infrastructure, as well as mocking all of the necessary API requests.

The initial render of the application was fairly easy. The only hitch was having to roll my own pause method to wait for any async API calls to complete before checking the component.

I'm currently stuck when trying to set input values in the UI. I can see that my event handlers are being triggered, but it seems that something in the Flux loops is causing an error. I'm getting the following error:

Invariant Violation: removeComponentAsRefFrom(...): Only a ReactOwner can have refs. You might be removing a ref to a component that was not created inside a component's `render` method, or you have multiple copies of React loaded (details: https://fb.me/react-refs-must-have-owner).

I've verified that I only have a single instance of React included on the page but I'm not sure what else would be causing that error (it obviously doesn't happen in the app itself).

joncursi commented 8 years ago

+1 for Capybara-like capabilities

pretentiousgit commented 8 years ago

I'm also stuck trying to set input values in the UI and seeing how they mutate. +1 for being able to fetch and set values such that it is similar to really typing into the input.

scottmas commented 7 years ago

This is a great idea. Imagine if enzyme supported jsdom integration tests out of the box. Since we'd be using jsdom, it would be super light weight and the tests could run on N virtual threads. This would massively parallellize integration testing in a way that just isn't possible with with full browser based integration tests, since browsers are too heavy on resource usage.

In the real world, integration tests are best at finding bugs where the shape of the data changes in the API's you're using, so a jsdom based integration tests using Enzyme full rendering should be both effective in catching regressions and being extremely fast to run. This seems like a big win to me.

Would there be any interest in creating a framework along these lines, either to be included in Enzyme or as a sister project? Using Enzyme as the test framework, jsdom as the test environment, and enabling parallel testing by default? I could take a stab at it

cannoneyed commented 7 years ago

Yeah, I'm very much in favor of pushing this forward as well - I've gotten pretty far with this but am finding there's going to be limitations because I can't access the instance() methods of a mounted component's children...

Here's an extremely contrived gist of how I'm currently approaching the idea of using enzyme and jest to "integration test" connected components:

// ConnectedComponent.js
class ConnectedComponent extends Component {
    fetchData = () => {
        this.props.fetchName()
    }

    render() {
        return (
            <h1>{ this.props.name }</h1>
    }
}

const mapStateToProps = (state) => {
    name: state.name,
}

const mapDispatchToProps = (dispatch) => {
    fetchName: () => dispatch(asyncActions.fetchName())
}

export default connect(mapStateToProps, mapDispatchToProps)(ConnectedComponent)

// test-utils.js
import { Provider } from 'react-redux'
import configureTestStore from 'shared/configure-store/test'

const Wrap = (Wrapped) => {
    const store = configureTestStore()
    return (
        <Provider store={ store }>
            <Wrapped />
        </Provider>
    )
}

// ConnectedComponent.test.js
describe('integration tests', () => {
    it('tests all the redux things', async () => {
        const Wrapped = mount(Wrap(ConnectedComponent)).find('ConnectedComponent')

        expect(Wrapped.props().name).toBeUndefined()

        await Wrapped.props().fetchName()
        // Ideally, I'd like to do the following to test component methods as well
        // await Wrapped.instance().fetchData()

        expect(Wrapped.props().name).toBeDefined()
    })
})

davidkell commented 7 years ago

The initial render of the application was fairly easy. The only hitch was having to roll my own pause method to wait for any async API calls to complete before checking the component.

@CrshOverride We are trying to implement a similar setup, how did you solve this pause issue? We do not have a direct handle on the function call (such as in @cannoneyed example above)

pudgereyem commented 7 years ago

I'm also interested in using enzyme to call Component methods instead of sending events when doing Integration (end to end) tests. I've found this blog post written by Class Dojo; https://engineering.classdojo.com/blog/2017/01/12/integration-testing-react-redux/

davidkell commented 7 years ago

After trawling through npm, we found this library: https://github.com/mlawrie/hereafter

The philosophy is pretty much what this thread is looking for:

"Hereafter lets you write concise, high-level, functional tests that provide similar coverage to your Selenium/Webdriver/Nightwatch/etc tests but execute hundreds or even thousands of times faster.

At the momement, Hereafter works with Mocha, Chai and Jest. I'm planning to add Jasime support, as well.

Hereafter defers evaluation of each line in your tests until the promises and callbacks triggered by previous lines have completed. In essence, it lets you ignore the fact that your code is asynchronous and write tests as though it were purely synchronous code.

Behind the scenes, Hereafter implements a similar polling scheme for expectations that you will find implemented in every functional testing tool. The key difference is that the polling happens much, much faster since there is far less overhead given that there is no web browser or DOM."

It works great for us and deserves many more stars !

martinp999 commented 7 years ago

@davidkell , not sure how it can be an integration test when you're not running in a browser?

davidkell commented 7 years ago

See the example on the main github page https://github.com/mlawrie/hereafter They use the enzyme mount method, which renders the React component with jsdom. Not sure why they say "no web browser or DOM", since jsdom is a DOM. I guess the point is that jsdom is so much more lightweight than 'real'/headless browsers.

martinp999 commented 7 years ago

@davidkell, thanks for the response. Any thoughts on using this approach vs real browsers? My concern is that it won't catch problems if, for instance, you had to support IE9 (not to mention latest Chrome, FF and Safari).

davidkell commented 7 years ago

@martinp999 Does enzyme support real browsers or just jsdom? But yes, indeed, it would never be enough to run the tests on jsdom for those reasons.