Open-Assistant
Open-Assistant copied to clipboard
LAION-AI
Write instructions and examples for unit-testing nextjs & react code
- [x] research pros and cons of different testing frameworks for nextjs applications
- [x] decide on a test framework (jest)
- [ ] implement a few example tests
- [ ] write instructions for other people who want to write tests in a README
note: this is mainly for testing the JS/TS code in terms of business logic. there is another issue tracking tests for the UI itself.
A request on however we setup testing, I think it'd be ideal for the React components to have their test code in the same directory as the component. This example from RedwoodJS is really clean and simple as all the code is in the same directory.
The same could go for any library code we end up writing.
From what I found, it seems that using Jest with React Testing Library is the standard for unit testing. Here are the Next.js docs for setting it up.
Jest
Pros
- Has support for mocking, snapshot testing, and code coverage
- Widely used by many to test frontend and backend code
- Next.js has a Jest configuration built-in since Next.js 12, powered by the Rust compiler
- Recommended in React docs
Cons
- Doesn't support TypeScript out-of-the-box
- Mocking dependencies may result in slow performance
React Testing Library
Pros
- Recommended in React docs
- Minimal configuration required
- User flow-based testing
Cons
- Different testing philosophy
Yeah, Jest was a pain to setup with typescript. Some projects have done this for you and it's something I wish NextJS did as part of their starter package.
Anyways, @ericv105 would you be interested in making an initial PR using either framework of your choosing and testing some of the library or handler code (or refactoring a file to make it more testable if needed)
Yeah, I'm working on setting up Jest and plan to write basic tests for some React components in the structure you mentioned before
I set things up last week but didn't get the chance to write some tests. Getting back to it tomorrow. Also learned that Cypress and Jest conflict because of the types they use like expect but it should be a simple fix.
I found a fix for the conflicting types by excluding cypress in the root tsconfig file and creating a separate tsconfig file within the cypress folder that extends the root file. But doing so doesn't allow cypress types to work in src/components/. So the Container.cy.tsx test in there breaks. Not really sure how to allow both testing libraries to work for react components. Should we just stick with Jest for unit testing components?
Since Cypress testing seems to be working pretty well and allows for testing component interactions, I'd prefer to not have to change how Cypress is configured or break Cypress.
I see in this cypress bug that others have had this problem with typescript. It looks like there's some ways to work around it. The fix you're describing, does it match what others have described?
If we have to, maybe we should just use jest for .ts libraries and leave all the component testing to Cyrpress. Cypress might be slower but it would at least provide for consistent UI testing everywhere.
I did come across that issue while searching for a fix and tried this suggestion and it didn't work but I did find a fix that's pretty much the same idea.
I also found that relocating cypress component tests into their own folder within the cypress directory and adding a specPattern to point to it in the component property in cypress.config.js allowed for it everything to work properly. Separating Cypress and Jest tests seems like the way to go. It's also suggested on the cypress docs as well.
We could still have Jest test files in the same directory as react components but Cypress tests would have to be separate for now. What do you think about this structure?
Ah, i didn't know Cypress recommends putting everything in a cypress subdirectory. I was hoping to avoid a subdirectory but this does let the jest tests be paired with the component code.
Before making this change, can you bring this topic up in discord in the #website channel and see if others have strong opinions? I'm leaning towards saying yes to your proposal.
Actually, it looks like we can have cypress component tests anywhere so long as they are in their own folder with a proper tsconfig file and updated specPattern. I think having one folder just for cypress component tests within the component directory is the best option. I just joined the discord and I will bring it up as soon as I'm verified and have access to that channel.
I think i just added you to the right discord role, you should be able to see the website channel now
We're currently relying on Cypress for now. No one's really worked on improving or writing jest tests. I'm going to close this as being outdated.