Should you use Jest as a testing library? (2022)
backend.cafe
backend.cafe
That said, Jest used to be so good when it was first released, and got gradually slower and more complex. Same with Yarn.
I hope React won't face the same fate. I loved integrating the recent suspense and async rendering features. It made my app feel so much better by removing loading flickers with no architectural changes.
I think the Jest situation is a little different as it was the incumbent not the challenger.
React is similar in the it's become an incumbent, though probably with less marketshare. Ironically I believe the lack of a virtual DOM is a big selling point for Svelte (sp?) which my frontend developers are really excited about.
Those are the "killer features" for yarn IMO, and why I think a lot of projects using it would have friction moving to npm
There was also an existing issue opened requesting this to be built in by a lot of people and facebook said lol no.
There are edge cases where you can't just drop it in directly as a replacement but you can very, very many times. Really makes me wonder what React is doing with that extra 93KB of JS, it's not actually even that fast compared to other frontend frameworks.
I strongly believe React team is shooting themselves on the foot by not making Error Boundaries into Hooks. If they did, someone could create a Preact 2.0 so to speak that is like React but purely functional (no classes). But since we don't have that, and error handling IS an important part of React, any react alternative would have to implement classes fully as well, which might retract many from even trying to create a React alternative (I don't think myself smart enough to do a React alternative properly, but I'd certainly tried if they did this).
> the API-compatible Preact is something like 7KB
Something is up here. Either Preact is not in fact API-compatible (in which case people should stop saying this), or the React devs are dummies who have never thought of Preact’s architecture or looked at its open source code (I rank this unlikely) or there’s somehow some other catch that no one talks about.
Which is it? Why doesn’t React just use Preact’s architecture if it’s so lightweight? What is Preact actually giving up?
Honestly to my mind the biggest thing is that bundle size just isn’t a priority for the React team. A sibling comment pointed out that React does a lot to correctly handle SVGs. Good to have, obviously, but what percentage of React users are making interactive SVGs? Probably not a whole lot. If they wanted to the React folks could break that out into a react-svg module or something and save some KB. But they don’t want to.
To my mind React these days is the enterprise software of the frontend. It’s big, it’s bulky, but it does absolutely everything with a minimum of fuss. They have a one size fits all approach and they’re not willing to deviate from it.
Every single app I worked on for the past 5 years did. `mui` icons are SVG for example, and it's common practice to embed SVG as components to avoid the HTTP requests overhead and allow for theming through props.
The syntax may be compatible, but the semantics are not. For example, it doesn’t support react's concurrency features; transitions are just empty wrappers.
React is a tiny fully agnostic library that does components, props, hooks and all that jazz. You can use it anywhere, from DOM to CLI. To tie it to DOM, a separate library exists—named, unimaginatively, ReactDOM—and that’s where the 100KB heft comes in.
Preact is the opposite: smaller, but coupled to DOM. The architecture probably doesn’t facilitate cool stuff like render components to embedded LCD[0], and even to do SSR you would have to add extra libraries.
[0] https://github.com/doodlewind/react-ssd1306/blob/master/docs...
React as a lib and architecture _is_ platform-agnostic. The core logic is defined in the `react-reconciler` package. It contains all the implementation of rendering components, diffing trees, managing state, and running effects, as well as all the "Suspense" implementation.
However, the way `react-reconciler` works is that it's built _into_ each platform-specific renderer implementation. So, the size of `react-dom` is actually the size of `react-reconciler` + all the DOM-specific behavior.
A quick check of https://bundlejs.com/?q=react-reconciler suggests it's about 100K minified. https://bundlejs.com/?q=react-dom is 138K, so that tells me that the DOM-specific logic is 38K.
I really like Vitest, and it's a great fit for lots of projects. I'm a bit sad it wasn't for ours.
I personally found Jest to do a lot of magic that, as an only occasional contributor to JS codebases, made it somewhat impenetrable.
As a comparison, many testing libraries look a lot like Python’s unittest if you squint, a design originated in the Java ecosystem I think. I find I can move between testing many languages and be immediately productive with test and know how things work, which is a huge productivity bonus.
Alternatively, I’ve found pytest’s dependency injection makes writing tests really nice and easy, the whole lifecycle management is very good. I’d even consider coordinating integration tests with it if I was just running precompiled binaries etc.
- Opening an editor split with a terminal
- Running Jest in watch mode
- Using a pattern to pick specific test(s) at a time
- Editing tests and code to either fix bugs or add features, and watching the test quickly re-run every save
Specifically the watch interface of Jest, which seems pretty simple, is great. It's a joyful way to work on code. Any test runner that doesn't support this workflow is a nightmare. And I don't get why many test runners don't support this workflow, it seems pretty easy to implement.
Ironically it's vitest that doesn't support this (IIRC, haven't checked in a minute)
We still use jest but it’s one of the slowest parts of our pipelines.
It does assume familiarity with testing in general (ie, how to design for unit testing, how to write clear tests, etc), but you'll need that to use any testing library effectively, and that skill is orthogonal to the library itself.
If you're looking for resources on that, I recommend: https://github.com/testdouble/contributing-tests/wiki/London...
“It” always caused weird grammatical problems with test descriptions. You can’t always describe tests that way. Some authors would try and some would ignore “it”.
I recently tried `bun:test` [1], which aims to become a drop-in replacement for Jest. It is quite good, but there is no way to do test coverage at the moment [2]. I am not sure that it will be fixed soon, as to my knowledge there is no test coverage instrumentation on JSC.
I replaced AVA with a minimal testing lib called Oletus [3]. It was also a delight compared to AVA. I am currently one of the maintainers of Oletus.
[1] https://bun.sh/docs/cli/test
Do you need to use an instanceof in the example code? I feel like it's already covered that in the first assertion, unless there's some horrifying way that another type could be implicitly coerced into an array looking shape.
expect(values.bar).toEqual(['a', 'b'])[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But this isn’t a silent failure, so it’s obviously detectable and therefore (if you know why) avoidable. It’s also so rare that you’d need to read a blog article to even know it was possible.
So I’ll keep using jest, because my tests all pass. When I hit one that doesn’t (and I can’t figure out why) I keep this in mind, but otherwise “not recommended” is overkill.
I still use Karma, but the GitHub says it's deprecated!