SSR component testing

[ruhaise]

Describe the feature you'd like:

Currently there is no documentation, recommendations or API's that I could find regarding testing components that are rendered in a server side context.

Suggested implementation:

Describe alternatives you've considered:

currently, I use the hack

/**
 * @jest-environment node
 */
import React from 'react'
import { renderToString } from 'react-dom/server'

const foo = () => <img src="bar.png"/>
describe('Server-side rendering', () => {
  it('renders on a server without crashing', () => {
    const foo = () => <img src="bar.png"/> 
    const renderOnServer = () =>
      renderToString(
        <main>
              <foo/>
        </main>,
      )
    expect(renderOnServer).not.toThrow()
  })

  it('renders with the src attribute', () => {
    const foo = () => <img src="bar.png"/>
    const ElementImageHtml = renderToString(<foo/>)
    expect(ElementImageHtml).toContain('src="bar.png"')
  })
})

[kettanaito]

I think what you may do is console.log(typeof window) in your test suite. If it's undefined the test is running in a NodeJS environment, which you can treat as server. If the window is defined, then it's up to the library to suggest a suitable solution, if any.

[ruhaise]

@kettanaito in my case its NodeJS environment, I want to really know if there is a built-in API to test server-rendered components.

[kentcdodds]

Hi @ruhaise,

I'm not sure to be honest. What I normally recommend is what you have there, though I can see how it could be useful to be able to traverse the output like it is DOM. What if we did something like this:

render(<ServerStuff />, {ssr: true})

I think what we'd do is basically:

const string = renderToString(yourUI)
container.innerHTML = string
// etc...

So you'd be able to interact with it like it's DOM, but it won't run your effects/etc.

What do you (and other's who are reading this) think?

[kettanaito]

So you'd be able to interact with it like it's DOM, but it won't run your effects/etc.

When would you want to interact with a server-side rendered DOM? Most (if not all) of the cases people assert the static markup rendered. Since user interaction happens on the client, client tests should test it.

Does providing a { ssr: true } option play nicely with the existing API? Are there any other options passed in a similar manner?

I think it's either making the render function smarter for the sake of unifying a rendering interface, or introducing a new API dedicated to SSR tests:

import { serverRender } from 'react-testing-library'

it('should render on the server', () => {
  const markup = serverRender(<ComponentsTree />)
  assert(markup).toContain("something")
})

I'd expect that the testing library inherits the environment it's being run in, so it's still worth mentioning that one must ensure their tests are running in node environment. I think if we run serverRender in jest, for example, the execution environment would still be js-dom. Perhaps it doesn't matter much, but the closer your test is to the actual execution context the better, so in jest's case it'd be about setting the jest-environment parameter in the header comment of the test suite.

[kentcdodds]

Hi @kettanaito,

When would you want to interact with a server-side rendered DOM?

I don't think you'd want to interact with it (and there wouldn't be any event handlers wired up anyway) but you might want to traverse it to make sure certain things are rendered properly.

Does providing a { ssr: true } option play nicely with the existing API? Are there any other options passed in a similar manner?

Yes, we currently also have { hydrate: true }

I agree that anyone using this feature would want to make sure they're not running with a real DOM.

This actually brings up a good point. If you're running your tests outside a jsdom global environment (as you noted people should) then how would React Testing Library create a DOM node to give back to you. Presumably it would create a JSDOM instance, but that would require that we add JSDOM as a dependency of this project and I do not want to do that. So then we'd have to say that you'd have to provide your own instance of JSDOM and if you have to do that then what good is us providing an API for you? It doesn't really do much more than you could do yourself.

Hmmmmmmmmmmmm....

[kettanaito]

Hi, @kentcdodds

I'm confused what would be the benefit of using react-testing-library API instead of a plain:

import { renderToStaticMarkup } from 'react-dom/server'

const html = renderToStaticMarkup(<Component />)
expect(html).toContain('class-name')

Since SSR output is de-facto a string, such test suite would use string assertions. Perhaps, there's some place for improvement that this library can fill?

[kentcdodds]

The benefit would be the ability to query the result like you do with regular front-end tests (using queries like getByLabelText). The problem is that we'd have to create a DOM for that.

I'm thinking that we should probably just put this in a separate package @testing-library/react-server which can have a dependency on jsdom to handle the creation of DOM nodes.

Thoughts?

[aw-davidson]

But does the user interact with server side rendered content before it reaches the browser? No. So, maybe the test setup needs to be rethought.

[kettanaito]

Since this kind of rendering is determined by the environment, I suggest not to have any explicit options like ssr: true, because they may contradict that very environment (i.e. testing SSR when being in a jsdom env).

Instead, render() could check the node environment and render to static markup correspondingly. Keeping the library's API consistent, the users would be able to use selectors like getByLabelText, as suggested by @kentcdodds.

[kentcdodds]

I'm sort of in favor of that idea, except in the case that someone thinks they're in a JSDOM environment but aren't really that could be really confusing. So I'd rather have something explicit and I'm thinking a separate package is the bet way forward.

Thanks for the discussion! So if anyone wants to take this over, please start the project yourself under your own github user and when it's stable, then let us know (here is fine) and we can talk about brining it into the org :)

Thanks a bunch!

[benmonro]

curious if anyone has seen / tried https://www.npmjs.com/package/happy-dom as it might be a potential way to do this...