Changing the default testing container

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
Search for a command to run...

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
No comments yet. Be the first to comment.
Most of you know me for my consistency, a golden arrow in my blog series. I've written 1000 articles in 1008 days! Almost an article a day, and my honeymoon was the only holiday I ever took. I'm super proud of this achievement; it has been a fantasti...

It's not the first time I'll be talking about community. I think it's an essential aspect of any successful tool. This shows in my previous explorations of Astro, Medusa, and now Vendure as well. All these products thrive in a super open, welcoming, ...

The cool part about Vendure is how easy it is to set up and how abstract each layer is. Basically, we get the following elements: External database Server Worker Admin UI Frontend While this is amazing, it also brings a bit of complexity when it co...

The previous article looked at customizing Vendure on a data and process level. In this article, we'll look at customizing emails, as they are often a big part of a webshop system. We'll be looking at two different layers of customization for customi...

Even though Vendure is a pretty significant project out of the box, in some cases, we might want to go in and modify some elements to work to our specific use case. In this article, I'll take a high-level look at some elements we can customize within...

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>
However, you might want to test for other scenarios in some cases.
I'll write two down that I have dealt with so far:
In those cases, we want to define another type of wrapper.
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();
});
Nothing strange so far, when debugging this code it would give us a HTML output like:
<body>
<div>Please login</div>
</body>
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),
}
);
};
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>
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),
}
);
};
The output will now be:
<custom-tag> Please login </custom-tag>
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 my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter