Changing the default testing container

dailydevtips1

Chris Bongers

Posted on April 17, 2022

Changing the default testing container

By default testing, the library will append your render to the body, for which it first will apply a div.

The format will result in something like this:

<body>
  <div>
    <YourComponent />
  </div>
</body>
Enter fullscreen mode Exit fullscreen mode

However, you might want to test for other scenarios in some cases.

I'll write two down that I have dealt with so far:

  • Custom component wrappers (custom elements)
  • HTML based emails (wrapped in table layout)

In those cases, we want to define another type of wrapper.

Defining a new wrapping container

For example, let's take the previous article. What if we want to render the App in a table?

This is the current test setup:

const renderComponent = ({ username }) => {
  return render(
    <UserContextProvider user={username}>
      <App />
    </UserContextProvider>
  );
};

it('should show the login option', async () => {
  renderComponent('');
  expect(screen.queryByText('Please login')).toBeInTheDocument();
});
Enter fullscreen mode Exit fullscreen mode

Nothing strange so far, when debugging this code it would give us a HTML output like:

<body>
  <div>Please login</div>
</body>
Enter fullscreen mode Exit fullscreen mode

Now let's see how we can add a Table.
For this to work, we have to pass an optional parameter to the render function called container.

const renderComponent = ({ username }) => {
  const table = document.createElement('table');
  return render(
    <UserContextProvider user={username}>
      <App />
    </UserContextProvider>,
    {
      container: document.body.appendChild(table),
    }
  );
};
Enter fullscreen mode Exit fullscreen mode

Running the above code would throw us an error, as we cannot directly append text nodes to a table.

But now, imagine the component we are testing is a TableBody component. It would make sense to test that inside a table.

The output would become:

<table>
  <TableBodyComponent />
</table>
Enter fullscreen mode Exit fullscreen mode

Testing custom elements

In my case, I recently had to test a custom component wrapper. This was mainly due to injecting something specifically in the shadow DOM.

The process for this is very similar. However, we define our custom element as the new tag.

const renderComponent = ({ username }) => {
  const customTag = document.createElement('custom-tag');

  return render(
    <UserContextProvider user={username}>
      <App />
    </UserContextProvider>,
    {
      container: document.body.appendChild(customTag),
    }
  );
};
Enter fullscreen mode Exit fullscreen mode

The output will now be:

<custom-tag> Please login </custom-tag>
Enter fullscreen mode Exit fullscreen mode

Be aware most components won't need a different container, but there are these exceptions where this can make your life easier to define one.

Thank you for reading, and let's connect!

Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter

đź’– đź’Ş đź™… đźš©
dailydevtips1
Chris Bongers

Posted on April 17, 2022

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related