5 ms·
In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape https://github.com/substa
by l1ambda 10y ago
In this case, I would argue it is not better. Many JS devs have moved onto simpler, greener pastures. https://github.com/substack/tape https://github.com/substack/tape is what I prefer. Small little library. Its API has everything I need and nothing I don't. Those other test libraries listed are pretty much overkill.
Similar with http://mithril.js.org/ http://mithril.js.org/ over React, Angular and Ember. A single drop-in library with 13 functions in it's API. The library itself is a single, understandable source code file. Mithril is pretty much the exact opposite of Angular and Ember.
A lot of front end devs are eschewing frameworks completely. With modern DOM and web APIs, you can do a lot with "just" vanillajs.
- tigershark 10y agoFrom the readme I can't really see how to write extensive unit tests with that thing.. If I need to test something I want only one tool that works perfectly and does all the Stubbing, Mocking, verification, data driven test and behaviour driven test. I still haven't found in any language/ecosystem anything comparable to Spock in completeness, readability and ease of use. Honestly I can't really see how to do BDD with tape.
- shados 10y agoits not that hard. That being said, the current all in one turnkey testing framework for javascript is Jest, and that will pretty much do it all in one tool.
- pcsanwald 10y agoBut, this is exactly what I'm saying. you start with a small, focused library that contains everything you need, which is usually fairly minimal, so that library is small. but then, along the way, you find yourself wanting, so you add a library that adds support for that specific thing. I didn't add sinon-as-promised for fun, I added it for in-memory sequelize integration tests. same for all the other libraries I mentioned. My point is that by keeping libraries small, you will end up with either more dependencies, or a lot more hand-rolled code. Neither of these things are inherently bad or good, and I'm not defending them. What I am trying to do is explain to the commenter why the node ecosystem seems to have such an emphasis on package management and the tooling around that.