Running Jest Tests in a Real Browser

[tom-sherman]

https://github.com/tom-sherman/blog/blob/master/posts/02-running-jest-tests-in-a-browser.md

Questions, comments, criticisms below please 😄

[remyrylan]

Thank you so much for the write up, Tom! I've got it working locally and so far everything is working great.

[tom-sherman]

@jrylan no worries, happy to help!

[Shingaz]

I'm working on the same kind of setup for I'm struggling the expect module as Jest does not provide a browser build anymore. I tried to process it with webpack + babel-loader but there is a dependecy to fs in 'expect` so webpack cannot find it in a browser context. How did you manage to bundle it?

[veliko]

In the webpack config:

resolve: { alias: { fs: false } }

[tom-sherman]

@Shingaz Just to so we're on the same page, what version of expect are you using?

[Shingaz]

I was trying with the latest one, I thought you managed to make it work with this one. It works with ^25.5.0.

[soulfresh]

For anyone else trying to get this working, this comment got everything working for me with the latest version of expect: jestjs/jest#139 (comment)

[trivikr]

From the blog post

Note that I have defined the parts of the Jest API I need, so if you use other parts then you may need to implement or import those too. The only thing that is not possible to use is the module mock API.

@tom-sherman What do you use for mocking modules in your test setup?

[tom-sherman]

@trivikr most of my code is pure with dependencies injected in. This allows me to pass in jest.fn()s as dependencies and assert if they're being called or mock their implementation.

I don't think module mocking is possible in the browser without significant changes to jest internals.

[fatso83]

most of my code is pure with dependencies injected in

This is how we write all our code on the backend side (Java): just pure and simple dependency injection via constructors. But this is highly unconventional in the Node/JS world as it would usually imply a big factory-style module at the top of the hierarchy wiring stuff up. For front-end code where one utilizes a lot of libraries, I see some major downsides to this, if you are going to pass down, say, lodash/pick to each and every module requiring it, in case you want to stub it out. How people doing this in practice (if at all), is something I wondered about for a long time. Do you have any example projects to show where this technique is used? Really wondering if there are no import calls in your lower level modules at all, or if there's a pragmatic mix.

I don't think module mocking is possible in the browser without significant changes to jest internals.

Module mocking in the browser level is not happening, unless browser vendors agree on implementing some loader hooks standard. To do mocking in the browser, it seems that one currently needs to do it at the webserver level, making aliases or import maps. Getting widespread tooling support for that does not seem to be happening anytime soon (but do let me know).

[fatso83]

In fact, the other Javascript test runners I've used don't include this type of mocking at all.

Traditionally this would be separate responsibilities: you would have a test runner like Mocha, a stub library like Sinon, an assertion library like Expect and possibly a link level module mocker like Proxyquire, and then you would make it all work. Jest is the odd man out in this regard, as it includes just about everything but the kitchen sink 👨‍🍳

I usually also try to avoid relying on stubbing at the link level, but sometimes you are not able to avoid it, as your SUT has some transitive dependencies with side effects you are unable to avoid. For instance, trying to run a module in Mocha that references Meteor packages that cannot be resolved outside of Meteor necessitated replacing import references with stubs to avoid crashing at runtime.

[fatso83]

@soulfresh I would be very interested in seeing some live examples of such a codebase. Haven't seen anything like it, I think.

One issue is for instance code like this:

<A>
  <B />
  <C />
</A>

Say C is a non-dumb component that changes global state, dispatches Fetch calls, etc. that messes things up, a simple approach for testing A is then mocking out C or its dependencies. Whether it makes sense it not depends, of course.

How would you normally approach this? One could use render props, passing in renderFooter={()=> <C />}, but that seem like a bit awkward design for one-off components, such as screens.

[soulfresh]

Starting with the caveats that I don't know Meteor and there maybe things specific to your environment I'm not considering...

In a React app I would use React Context to inject the dependencies of C. I remember Angular has a DI system but I don't remember how to use it. I wish I could show you a working example but I don't have a public repo to share. I'll update my starter kit this weekend to show a working demo.

I'll make your example more concrete:

<App>
  <ServiceProvidersHere>
    <MainLayout>
      <Header />
      <Router>
        <DynamicallyRenderedPage>
          <DumbPageLayout>
            <DumbComponentsFromHereOn />
          </DumbPageLayout>
        </DynamicallyRenderedPage>
      </Router>
      <Footer />
    </MainLayout>
  </ServiceProvidersHere>
</App>

I think the <A> in your example would be my <App> and your <C> component would be my DynamicallyRenderedPage. DynamicallyRenderedPage is going to fetch data from a GraphQL backend. I would use a custom service to make those requests so I don't have GraphQL requests directly in my DynamicallyRenderedPage (a vanilla class MyBackendAPI with functions like myService.getUser()). The service could also be a library like Axios.

To mock my service in tests (or I also have a yarn start:mock that runs the app with mock APIs), I will either inject the MyBackendAPI service or use an environment variable to switch between the mock and live APIs. So for a full integration test of the app, I would pass MyBackendAPI as a prop to App which would use React Context to provide that service to the rest of the app. Then in DynamicallyRenderedPage I would const api = useContext(MyBackendAPIContext) to get the mocked service.

I like to keep everything below DynamicallyRenderedPage as dumb components that receive data and config via props. That way dependency injection in 90% of my tests is just prop passing. Integration tests are always tricky but with dependency injection I have full control over the SUT.

Hopefully the above makes sense and I'm answering your question. I've been meaning to update my starter kit so I'll do that soon and post a link.

[fatso83]

Thanks for the example. Was a good one.

In a React app I would use React Context to inject the dependencies of C.

I regarded the imported components as dependencies of your component as well, so that's why I was wondering how you managed all of that using constructor injection. I see now that you generally just think of the "smart" parts as dependencies, and then it makes a bit more sense.

Wrt Meteor, Meteor runs in a non-standard Node runtime (at least it used to), so module resolving would refer to modules that were not present in a normal Node runtime (such as the one created when running Mocha tests). So modules trying to resolve import Meteor from 'meteor' would crash in Mocha, hence the need for a module loading proxy like proxyquire to avoid that.

Been 3-4 years since I touched Meteor though, so not all that important anymore, but served as a good example 😃

[soulfresh]

FYI, I updated my starter kit to show how I inject mock services into my apps during testing and development. I'm afraid I don't have time to get the tests and mock server working but they are 95% there. Take a look at App.test.jsx to see how I inject my service in integration tests. Injected services can be passed into the App component and flow into the WithMocks component where they get provided to the application. The Home component shows how those get used in a page component. There are a lot of moving pieces in there but it's a useful setup.

https://github.com/soulfresh/react-website-template

Hope it's useful.

[viglucci]

Is there by chance a fully working example of this setup somewhere?

[soulfresh]

@viglucci I've just updated my react website template with a working example of Jest tests running in the browser: https://github.com/soulfresh/react-website-template

It comes with the caveats mentioned by @tom-sherman; Jest mock does not work in the browser so you can't expect(someSpy) to work. However, you can expect(getByText('Button Text')) to work. To give it a go, clone the repo, yarn install and then yarn test-browser --testPathPattern=App to run the App integration tests.

I only use yarn test-browser to help me debug components in the browser because I find it really useful to see the visual representation of the DOM when I'm trying to debug failing tests. It's also nice to be able to use the Elements panel in the Developer Tools. When I'm not debugging in the browser, I use yarn test or yarn test-debug to run the tests against jest-dom.

Let me know if you run into any issues getting it to work.