Cathal Mac Donnacha
banner
cathalmacdonnacha.com
Cathal Mac Donnacha
@cathalmacdonnacha.com
Principal Frontend Engineer @wpengine.

Follow along for frontend tips on React ⚛️ Testing 🧪 UI/UX 🖥.

My blog ✍️ http://cathalmacdonnacha.com
Hey Artem, curious if you ever get around to this one? If so, how did it go?
August 22, 2025 at 11:22 PM
Google cloud build
June 2, 2025 at 11:22 AM
We find our current jest/JSDOM/testing library setup varies quite considerably. Our fast Macbooks run test quote fast, but can sometimes fail on our CI machine due to timeouts.
June 2, 2025 at 10:51 AM
How do you manage the difference in test times between local and ci? Tests which run fine locally could be slow on ci and timeout/fail. Depends on the resources used on the ci machine I guess.
June 2, 2025 at 10:20 AM
I love the idea, but if I was to try and evangelise this in my team I feel like it would just come across as another thing to maintain. I can't say we've hit a pain point where API field changes have broken things either as we have good communication. Still intrigued though!
June 2, 2025 at 10:13 AM
For sure. I'm cool to use it if it's in and around the same speed, and of course there's a trade off with gaining confidence with less mocking, but if a test suite takes double the amount of time, that's double the resources on our CI/CD machine, which could be a no-go.
April 3, 2025 at 1:33 PM
Nice, I think I just need to sign up to the course 😁

That's the amazing thing, less mocking when not needed.

Have you noticed much of a speed difference between browser mode and running the likes of JSDOM?
April 3, 2025 at 1:30 PM
Yea, mocking "navigate" in jsdom has been a pain for us.

Have you experienced slower test speeds given you're spinning up a browser?
April 3, 2025 at 1:21 PM
I wonder what the reluctance is to move it from experimental to beta? For better or worse, companies I've worked for in the past have had policies to only use production ready libraries. Beta or experimental weren't allowed, no matter how safe they were perceived to be.
April 3, 2025 at 1:20 PM
Nice. I'd be interested to hear about that experience in terms of speed and dx differences. Right now our jest tests often time out. We also often have to mock "window.location" if a button triggers a "navigate" to another URL. Can those scenarios be handled in vitest browser mode?
April 3, 2025 at 1:17 PM
Yea I have been following browser mode in vitest, but it's still in experimental mode right? I don't think I could recommend it to my teams just yet until it's production ready. Do you find it much slower compared to a typical jest test?
April 3, 2025 at 12:43 PM
I have been keeping an eye on that, but as far as I know it's still in experimental mode right? I wouldn't be able to start recommending that to my teams until it's production ready tbh. Looking forward to that though. Is running in browser mode with vitest slower than a typical jest test?
April 3, 2025 at 12:41 PM
Do you still use Jest/Vitest with React Testing Library? I would much prefer testing using a real browser, but have always found these to be much faster to write and easier to maintain.
April 3, 2025 at 2:53 AM
We actually use Playwright as well and I did up an ADR to compare it with Cypress before pulling the trigger. It's outdated, but these were the reasons:

cathalmacdonnacha.com/cypress-vs-p...
Cypress vs Playwright: Which is best for E2E testing?
Cypress was our go-to end-to-end (E2E) testing tool, and we were pretty happy with it, up until recently that is. Lately, we've run into a couple of testing scenarios where Cypress support has been limited, notably around multiple domains/tabs and iF...
cathalmacdonnacha.com
April 3, 2025 at 2:49 AM
This is really nice for those obvious mistakes, thanks for adding it! My fear though is that junior devs will blindly commit suggestions, even though they may not be correct.
April 2, 2025 at 7:35 AM