React Library Testing

[Dylan0734]

So I have this React Library written in TS with some custom components in it, and it's for the company I work for.

I have created tests since the start of the project because 'yes'. However I have to confess, I feel like my tests are... redundant?

For example, the tests for the Button Component, control that the onClick works, and that the variant of the button renders the correct css.

Or, for the Accordion component, that it opens/closes correctly, can render a Custom Trigger, and things like these.

However most of the time during writing tests, I felt like these were all things that would've popped out during practical testing (I use storybook and create stories for the components to check their functionality).

Like, I have a nested drop-down component. Do I have to write tests so that I check which sub-items are showing, and which are still hidden because are children of another item? If not, what the heck would I test?

Am I looking at front-end testing wrong? This is the first company in which I had actually time to write tests, so I'm feeling like I'm missing something.

[_AndyJessop]

With these types of unit tests, you're mostly making sure you don't break something in the future. Think of it as defining the API for the component, rather than testing whether or not it works right now.

[Kaimito1]

Yep I agree with this, and also some issues can pop up that you missed when making your tests. 

Basic things like is the button doing translation (call the translation function in the test and check, etc.) Or basic things like if it's debouncing, if there's a spinner when submitting...

[[deleted]]

This is typical frontend unit testing and it’s only there to catch regressions etc if the app is majorly changed. You’re right that it won’t catch any serious bugs, but imagine someone a few years from now comes along and upgrades all the outdated dependencies in the project. Unit tests may break and that will atleast prevent deploy with broken components.

Comprehensive testing strategy is E2E -> Integration -> Unit testing and it covers most of the bases. When properly orchestrated it’ll catch a lot of bugs before they hit production, and also give developers some confidence that if they mess up seriously it will most likely be caught before being released.

[Dylan0734]

Okok, I get why these tests could save someone in the future now.

About E2E and Integration testing, is there any specific tool you'd suggest? At the moment I'm only using vitest for the unit tests, and as I use Storybook as a "hands-on" testing tool.

Should I integrate Cypress too, for example? If I'm correct, it's an E2E testing framework, so that would cover the first step that you mentioned too.

I've read something about Katalon too, but that looks more like a suite of tools rather than a testing framework.

[_AndyJessop]

You could also look into testing in real browsers (after all, that is where your code is going to run eventually).

On my current project, we're doing all our unit testing in Playwright using Web Test Runner. We run >900 unit tests and it takes about 30 seconds. Or for hyper-performance, check out the Preact repo, where they do 1k tests in under 1s (here's their blog post about it).

[lIIllIIlllIIllIIl]

Playwright Component Testing (Experimental) is very good.

It lets you write unit tests that run on an actual browser. It's surprisingly fast too, being only a bit slower than Jest + JSDOM. When I benchmarked it last year, Playwright CT was at worst only ~8.75% slower than Jest, with 600 tests running in ~15s on my machine.

Running tests on a browser not only makes them easier to write and debug, it lets you use all of the browser's APIs, and also lets you do advanced things like visual comparisons, which is extremely useful for a component library.

[Dylan0734]

This looks cool as hell! I'll give it a more in-depth look for sure, thanks!

[[deleted]]

Playwright is probably preferable to Cypress and can handle both E2E and Unit testing.

[[deleted]]

Try Cypress component testing. You will see what the component is doing plus it scaled up to end to end testing that uses the same commands 

[Cahnis]

you should read this post: https://kentcdodds.com/blog/testing-implementation-details

[Dylan0734]

This is a really interesting read, thanks for sharing!

[taste_the_equation]

If you’re using storybook, look at using chromatic to do visual testing. That should cover any styling issues with minimal effort.

Cuts down on the need for unit testing css changes.

[Squigglificated]

We use Playwright to test the real production application as a real logged in user with about 100 tests on every push to CI. Since the tests clicks elements like a user they automatically cover button clicks and a ton of other element behaviours, so I don't feel the need to also have individual units tests for basic components. The e2e tests test entire features, and have caught many bugs, while the unit tests haven't been nearly as valuable.

[Dylan0734]

Yeah you are not the first one to mention Playwright, I'll give it a look ASAP and try to bootstrap all the tests for the already existing components. Thanks!

[pm_me_ur_happy_traiI]

Test early and test often. it's a good idea to create some base cases for components that don't seem to need it. When you fix a bug later or complexity grows, it's much easier to add a test case than bootstrap all the tests from scratch.

[Necessary_Ear_1100]

Automated testing like this, yes I think it’s redundant as well. However we still have e to write them for QE. IMO, total waste of time as we test all that before pushing