We've just spent the worst couple of hours trying to work with Jest with SVG, nanoid, ... Anything that's slightly out of the ordinary Jest won't work and we found out we were spending more time debugging Jest than debugging our code. So... please help us. How do you survive the testing hell??
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (20)
- Winston Churchill
Does that help you? π
Lol. I'm more tempted of turning around and never testing again!
As for everything, it's first difficult and tempting to quit, but then it suddenly just becomes a new normality for you and it's not difficult anymore, maybe you even start to like it.
Frontend testing can be hard; but oftentimes when you're having issues writing tests, it's because something is wrong with your code. Poorly designed architectures are hard to test, especially when they stray from the conventions the testing frameworks are designed for.
Check out testing-library, stop testing implementation details like SVGs, maybe really consider switching to vitest.
Covering existing code with tests is usually a nightmare, try doing it the other way around next time (when youβre refactoring or fixing a bug). Testing shouldnβt hurt that much, even with Jest.
Try to split your components into βdumbβ view layer and βlogicβ functions, they should be easy to test:
The next in the line would be βcomponentβ tests, that would check the component that connects your many small functions together:
With that said, not everything is worth automating, no automated tests is sometimes better than flaky tests and tests that are breaking on every code change. But some good tests are always better than none, so just try and find the best value for the time spent.
That's really helpful, @valeriavg, thanks!
Is there any chance that maybe you are holding it wrong? Try opening a stackoverflow ticket! Personally I have had mostly joy of Jest and not framework specific issues. For my use cases there have been great documentation as well as community posts about all the questions I have been looking for. Mostly, at least.
If you use SQLite or your queries are generic SQL, you should switch to using SQLite under in-memory mode for your DB driver during testing. It's extremely fast to bring up and tear down an SQLite DB. You don't need to deal with setting file paths, and you can have multiple SQLite DB instances open. Cleaning up is easy since it's in memory.
Frontend testing is... yeah, I understand your pain. I try and make it a habit and do it consistently, so I'm not having to write a whole bunch of tests all at once. But still, I have an entire file that isn't tested because MSW and Vitest simply refuse to cooperate with each other :p
Tell me about it... I think we've found our one file like that.
For testing to work and scale well, you must have a test-driven development process from the beginning.
TDD code will work differently than freeform jazz odyssey code. You and your team need to be on board, and management needs to support this. It is very common to have code that works, but is difficult to test. It is helpful to have somebody with deep experience in testing to help out and train your developers.
I have worked at my employer for eight years, and I must say that the payoff in clarity for TDD is real. However, the benefit is often years away.
A feature is written and it works, whether the code is TDD or not. Can your team write TDD at the same speed as untested code? With practice you can, but it is not easy.
If you are working on something like a public API or banking software, a unit test would be very important because other people expect consistency and the cost of bugs/errors is high.
You might want to consider partial coverage: test your transaction code thoroughly, but don't test buttons or layout.
Have you tried vitest (vitest.dev/)?
IMO the easiest and fastest way to do unit tests :). But if your trying to do sth. very niche, there might only support for it in jestβ¦
Testing that's slowing you down is better than writing code with no tests and moving fast.
10/10 times
Some comments may only be visible to logged-in visitors. Sign in to view all comments.