DEV Community

Cover image for Testing hell 😱. Honest question. How do you survive? What's your secret?
OpenSource
OpenSource

Posted on

Testing hell 😱. Honest question. How do you survive? What's your secret?

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??

Top comments (21)

Collapse
Ā 
ben profile image
Ben Halpern •

If You're Going Through Hell, Keep Going

- Winston Churchill

Does that help you? šŸ™ƒ

Collapse
Ā 
opensourcee profile image
OpenSource • • Edited

Lol. I'm more tempted of turning around and never testing again!

Collapse
Ā 
framemuse profile image
Valery Zinchenko • • Edited

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.

Collapse
Ā 
valeriavg profile image
Valeria •

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:

  • Come up with a type or interface that is elegant and does exactly what’s needed ( i.e. describe function arguments)
  • Write mock data / test cases ( i.e. input/output pairs following the structure you defined)

The next in the line would be ā€œcomponentā€ tests, that would check the component that connects your many small functions together:

  • Try testing-library, as mentioned, with it you can write a11y driven tests, I.e. select elements based on their roles and titles like a person with a screen reader would
  • If you’re struggling with mocking complex functionality try msw (mock server worker) that lets you easily mock any api request
  • Consider using Storybook or similar if you need visual testing, you don’t need to incorporate automated visual regression tests unless you have to, but you would be able to make manual testing easier

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.

Collapse
Ā 
opensourcee profile image
OpenSource •

That's really helpful, @valeriavg, thanks!

Collapse
Ā 
emmadscodes profile image
EmmaDSCodes •

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.

Collapse
Ā 
lexlohr profile image
Alex Lohr •

Check out testing-library, stop testing implementation details like SVGs, maybe really consider switching to vitest.

Collapse
Ā 
hilleer profile image
Daniel Hillmann •

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.

Collapse
Ā 
kurealnum profile image
Oscar •

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

Collapse
Ā 
opensourcee profile image
OpenSource •

Tell me about it... I think we've found our one file like that.

Collapse
Ā 
chris407x profile image
chris407x •

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.

Collapse
Ā 
martinbaun profile image
Martin Baun •

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.

Collapse
Ā 
makscraft profile image
Maksim Zaikov • • Edited

Unfortunately sometimes you need to write something like backdoor to test the frontend code. It's may be very dangerous for production ENV, but you will need to make it workable only for local ENV, running only on localhost and in this case your code will be safe and secure.

Collapse
Ā 
falkz profile image
FalkZ •

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…

Some comments may only be visible to logged-in visitors. Sign in to view all comments.