Question: Nested component that has `useRouter` tests are taking much longer
JeffBaumgardt opened this issue · comments
I pose this as a question and not a bug.
I have a new nextjs instance (13) and I've setup two brief routes.
/pages/index.tsx
/pages/test/index.tsx
The first index, or root, is currently just a span of text. Test is running great.
The second page (test) has a few layout components, ie head, aside, main. I have a navigation link section in the head. The individual links have a useRouter
hook for active styles.
I mock out the router since the hook will throw without context and run a simple expect test.
It works, the text is found within the layout and I'm happy, mostly.
The test is taking 15s to run. I have 0 external data at the moment, no async code to be found. I'm not currently testing route transitions just span text.
First test (passing, near instant)
import {render, screen} from '@testing-library/react'
import App from 'pages/index'
describe('App Landing', () => {
test('Renders text', () => {
render(<App />)
expect(screen.getByText('This is some sort of login screen perhaps.', {exact: false})).toBeInTheDocument()
})
})
Second test (passing, 15s delay)
import {render, screen} from 'test/test-utils'
import App from 'pages/test/index'
describe('Test Landing', () => {
test.only('Renders the Test', () => {
render(<App />)
expect(screen.getByText('Test', {exact: false})).toBeInTheDocument()
})
})
Both tests are very simple in asserting text. The difference between the pages again is the first is only a single span, and the second has presentation containers with a navigation container with link
<NavigationWrapper>
<NavLink href="/test/1" title="One" />
<NavLink href="/test/2" title="Two" disabled />
<NavLink href="/test/3" title="Three" disabled />
<NavLink href="/dash/4" title="Four" disabled />
</NavigationWrapper>
The NavLink component is just a next/link
component with a useRouter
hook to attach an active class for styles.
I'm just trying to see if anyone has experienced something like this and what you did to help solve it. I'm ok with it as is because it's technically working, but I would like to not rack up a lot of wasted cpu time once these tests make it to CI.
Hmm ... Interesting issue!
My first question is whether you can isolate the problem ... Does commenting out the useRouter
logic fix it? Or maybe removing half the links, does that speed it up?
In general, next-router-mock
doesn't do anything expensive. Each useRouter
call does little more than Object.assign
.
With a 15s delay, I would guess that you've got a rerender loop, but you should be sure to isolate the issue first.
Yup that was my next steps last night. I'm still trying to track it down, but it is unrelated to the mock router. As I removed the entire header component and it still ran in 10s. I have a working theory that it might have something to do with MUI and emotion, but there's more testing to be done. Sorry for bothering you and wasting an issue.
No worries, I appreciate your polite and humble approach, and I'm relieved it's not a mocking issue.