11 ms·
Should you use Jest as a testing library? (2022)
- locallost 3y agoOne of the reasons I always preferred running tests in real browsers with Karma.
- syspec 3y agoSame! Is there a modern equivalent? I still use Karma, but the GitHub says it's deprecated!
- codefined 3y agoVitest[0] is a drop in replacement to Jest that we've had exceptional success with. Faster test runs, more reliable, default TS and ESM support, etc. [0] https://vitest.dev/ https://vitest.dev/
- ehsanu1 3y agoThat seems tied to Vite though?
- zerace 3y agoIt's actually not! You can use vitest in a node environment as well just fine.
- thatswrong0 3y agoIt's an _almost_ drop in replacement - when I tried migrating our tests recently (because of memory leak issues / slowness resulting from Jest + a Node upgrade) I found I had to manually finagle a lot of our mocks to get them working.
- seniorsassycat 3y agoDoes vitest have this same issue or make a trade off to avoid it like jest-light-runner
- seniorsassycat 3y agoBig fan of vitest, I like typescript and esm support out of the box and without adding dependencies like types/jest or ts-jest. I've filed bugs and pull requests and the maintainers have been responsive
- xer0x 3y agoVitest may not be a good drop in replacement either. It uses Workers for multi-threading via Tinypool. For us, we use the AWS SDK and the binaries in it would cause Vitest to crash. After wasting a lot of time, we had to retreat back to Jest. I really like Vitest, and it's a great fit for lots of projects. I'm a bit sad it wasn't for ours.
- shitlord 3y agoJust curious, were you using v2 or v3 of the AWS SDK? I was going to try Vitest after reading these comments, but maybe it's not feasible right now.
- deanc 3y agoIt is most definitely not drop in. I looked into this yesterday funnily enough and you can expect to have to make many syntax changes to your test files.
- jonahx 3y agoIf you're looking for a minimalist framework that can be learned in 10 minutes or so, I recommend "ospec". For me it was a delight compared with Jest. https://github.com/MithrilJS/ospec https://github.com/MithrilJS/ospec
- yawnxyz 3y agoWow that's so refreshingly simple. Do you have any recommended / official tutorials or cookbooks for this, for web projects?
- jonahx 3y agoAs far the library itself goes, the README is all you need to know. That's what's great. 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-school-TDD https://github.com/testdouble/contributing-tests/wiki/London...
- fourthark 3y agoI like that ospec does away with the `it(...)` convention in favor of “bullets” “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”.
- conaclos 3y agoNice project! I will have a look at 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 https://bun.sh/docs/cli/test [2] https://github.com/oven-sh/bun/issues/3158 https://github.com/oven-sh/bun/issues/3158 [3] https://github.com/bearror/oletus https://github.com/bearror/oletus
- fathyb 3y ago`instanceof Array` is a famous JavaScript footgun you should not use anyway. The same happens when sharing objects with an `iframe` (aka "cross-realm objects"). This is why `Array.isArray` exists. 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.
- CSMastermind 3y agonpm took up most of yarn's significant changes to the point where I switched back years ago. 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.
- pcthrowaway 3y agoI mostly use npm, but does npm have anything like yarn's workspaces or ability to patch dependencies with project-specific changes? Those are the "killer features" for yarn IMO, and why I think a lot of projects using it would have friction moving to npm
- uallo 3y agohttps://docs.npmjs.com/cli/v9/using-npm/workspaces https://docs.npmjs.com/cli/v9/using-npm/workspaces https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package
- meese712 3y agoThink the biggest slow down is from it running all the test suites in isolation in separate contexts (think that's the right word). I got frustrated with how slow our frontend tests were one day like 4 years ago and wrote a hacky jest runtime that reused the context unless it detected jest.mock or jest.spy or timer stuff in the file it was on. It speed it up by 2x with cache cleared. It was still pretty slow though... There was also an existing issue opened requesting this to be built in by a lot of people and facebook said lol no.
- throway23yjl234 3y agoIt's well-known to use `Array.isArray` instead [0]. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray#instanceof_vs._array.isarray https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- olliej 3y agoOh is this just the multi global issue you have on the web?
- Zetice 3y ago> This means that the instanceof operator will not work as expected, and it will generate false negatives! 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.
- afro88 3y agoExcept when you test that something is *not* an instance of something else and the test wrongly passes. Then you'll be scratching your head trying to fix a bug already in production.
- bottlepalm 3y agoA bit a click bait title, are we really advising to throw out Jest because of a single hang up?
- jaktet 3y agoDespite the title this thread has brought up numerous other pain points with jest that make it less than ideal. At the cost of ensuring tests don’t bleed into each other due to the virtualization that occurs running large suites of tests in jest is extremely slow. We still use jest but it’s one of the slowest parts of our pipelines.
- EdwardDiego 3y agoSo this is like the iframe Array isn't the same as the parent window's Array issue? I guess both Array types are same in semantics, but have different prototypes for isolation so code in one context can't dick with code in another context in a language where dicking with other code trivially used to be very commonplace. Good ol Prototype.js used to love extending every DOMElement prototype it could. 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'])
- stevebmark 3y agoClickbait, hard skip. Jest is the best testing framework I have ever worked with, every other testing framework should learn from it (seriously). Iterating on tests in watch mode is a joy.
- golergka 3y agoHave you tried vitest?
- rozenmd 3y agoIf you love iterating on tests in watch mode, Vitest will feel even better: https://maxrozen.com/beginners-guide-to-react-testing/react-testing-tools-how-to-use-them https://maxrozen.com/beginners-guide-to-react-testing/react-...
- yakshaving_jgt 3y agoNot being sarcastic, but what qualifies your opinion? i.e., which other testing frameworks and/or language environments have you used?
- danpalmer 3y agoI’d love to hear more about your reasoning because it’s not the experience I’ve had, but I’ve heard it before and would like to understand it more. 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.
- stevebmark 3y agoThe specific workflow for Jest I really enjoy: - 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.
- omgmajk 3y agoI much prefer Mocha to Jest together with some other things. I guess you get used to what you know.
- ruffrey 3y agoThe main reason I’ve ended up migrating Jest projects to mocha is for backend integration tests using the db. Jest is clearly built for the frontend first. It needs workarounds to run sequentially. That’s important for setting up and tearing down a certain specific backend app state for a test. startup scripts (db teardown and migrations maybe) are tough to configure with typescript, or even at all. generally typescript is tough to configure at all with Jest. Nested tests do not always work predictably with setup and teardown. The mocking and spies aren’t as good as Sinon or nock. expect doesn’t allow a fallback error message like plain assert (just a pattern, no lock in to jest there). running jest with a debugger requires annoying re-configuration per specific test in Jetbrains because Jest has its own VM, doesn’t pick up subtle config, and jest doesn’t often run your code in the same way as plain nodejs due to the vm.