tests(react-router): add some basic runtime tests for Link
#1590
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit e73be4c. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
chorobin
force-pushed
the
link-runtime-tests
branch
from
e8cc05e
to
e6936b7
Compare
| history: createMemoryHistory({ initialEntries: ['/'] }), | ||
| }) | ||
|
|
||
| await router.load() |
There was a problem hiding this comment.
For real-life testing, should we be doing the router. load() stuff? Because that seems like a departure from what's really happening at runtime
There was a problem hiding this comment.
How about rendering the router provider and then just waiting for something to be visible on the screen? Shouldn't the loaders be triggered automatically?
There was a problem hiding this comment.
Yeah. I just thought I can do this. Stuff like loader, validateSearch and beforeLoad should be ran automatically so I just want to test if they did something. Like redirect or show data returned from the loader etc
SeanCassiere
changed the title
LinkLink
chorobin
force-pushed
the
link-runtime-tests
branch
from
e6936b7
to
cbf3845
Compare
chorobin
force-pushed
the
link-runtime-tests
branch
4 times, most recently
from
3c09f4a
to
7ab1283
Compare
| cleanup() | ||
| }) | ||
|
|
||
| describe('Link', () => { | ||
| it('should NOT pass the "disabled" prop to the rendered Link component', async () => { | ||
| test('when a Link is disabled', async () => { |
There was a problem hiding this comment.
Is there any reason test is being used instead of it?
There was a problem hiding this comment.
I personally prefer actually no nesting in tests. And to just use test. I like my tests super simple
| }) | ||
|
|
||
| expect(postLink).toHaveAttribute('href', '/posts/id1') | ||
| expect(postLink).toHaveAttribute('from', '/posts/') |
There was a problem hiding this comment.
Is this checking the <Link> component as React node? or the actual HTML that's printed to the document?
If it is the <Link> component, then cool 👍🏼.
But if it is the HTML anchor element being printed to the document, then maybe that's actually a bug/unintended behaviour? Since from is not a valid HTML Anchor attribute, then it's probably not something we should then be expecting to available in the DOM.
There was a problem hiding this comment.
Yeah, I guess this is a bug!. It's the a tag
| expect(onError).toHaveBeenCalledOnce() | ||
| }) | ||
|
|
||
| test('when navigating to /posts with a beforeLoad that redirects', async () => { |
There was a problem hiding this comment.
In the future perhaps, this should be moved to redirects.tests.tsx and be tested at runtime using both <Link> and a button wired up to useNavigate().
There was a problem hiding this comment.
I guess its hard to know where it truly lives. But I wanted to test the user pressing a link and it redirecting them because I think that's how it's actually used
| const postsLink = await screen.findByRole('link', { name: 'Posts' }) | ||
|
|
||
| expect(postsLink).toHaveClass('inactive') | ||
| expect(postsLink).toHaveAttribute('href', '/posts') |
There was a problem hiding this comment.
Could a test also be added in, testing the href value when a basePath value is set on the router.
const router = createRouter({
basePath: '/app'
})Seems like a good runtime check to guarantee.
chorobin
force-pushed
the
link-runtime-tests
branch
from
7311e9d
to
89e3c90
Compare
chorobin
force-pushed
the
link-runtime-tests
branch
from
89e3c90
to
e73be4c
Compare
Again quite high level to test navigation and not internals. I will add some more but wanted to know if you guys are ok with basic high level tests like this