Full disclosure: I’m a maintainer of Mocha.
Regarding point #1, “Too Much Configuration”: Mocha is guilty of this (I guess?), because it provides choice. Choose the assertion library you want to use. Choose the mocking library you want to use. Choose BDD, TDD, QUnit style, “export” style, write your own, etc. Clearly for many users, having the choice is important.
Jasmine, on the other hand, pretty much comes with everything you need to get running quickly, so I’m not really seeing the “too much configuration” argument. (Either way, if you need some of the features Jasmine & Mocha have which Tape does not, you are probably going to be writing more code and fixtures. I’m of the camp which would rather just configure something to my liking.)
Regarding point #2, “Globals”. Depending on the interface, Mocha will reserve some globals. Believe it or not, it’s pretty convenient! However, you can use the “export” interface and avoid globals altogether. If Mocha’s globals conflict with your app’s globals, why does your app have globals? The article mentions about how you shouldn’t need too many mocks if your app is well-designed; I’m assuming “your app” is fair game here.
Of practical relevance, I’ve never seen an issue come through where someone was complaining that we were blasting their global beforeEach() function.
Regarding point #3, “Shared State”. As you mention in the notes above, “Mocha encourages you to write code using shared state” (paraphrased). Mocha isn’t in the business of making people write dirty unit tests. Mocha’s a tool, and you can misuse it if you wish. You wrote it yourself, regarding beforeEach() and its ilk:
You don’t need these. They’re bad for your test suite. Really. I have seen these abused to share global state far too often.
However, if the documentation actually encourages polluting test state, I’ll see about changing it to discourage this behavior.
I’m sure I could find a way to do something awful with Tape too!
To a couple other points:
“Solutions like Mocha and Jasmine are harder to fit into your continuous integration pipeline than tape.”
This is a rather broad generalization, don’t you think? I’ve had absolutely no problems working Mocha into any CI pipeline I’ve worked with thus far. Mind you, I’m not in the Microsoft or Java ecosystems.
If a CI server is having problems understanding Mocha and does understand TAP output, you can always use Mocha’s TAP reporter.
Do you really need an end-to-end solution that thinks its way is the only way,or do you want a solution that you can literally plug into any standard system workflow?
I’m starting to worry I am feeding the trolls here, but isn’t this article telling me the only way is to use Tape? Again, Mocha is all about choice (Jasmine, on the other hand, not so much). Should I ask you to define what a “standard system workflow” is, exactly? And into which outlet do I insert my plug..?
If you’re writing for 100% coverage (and you should be), your test suite is likely to be larger than your application
OK, I’ll bite. If you are writing for 100% coverage, won’t the time and money you claim would be saved by using Tape be instead frittered on developers writing meaningless unit tests just to reach that mythical 100% number? I suppose you’ll tell me no, for some reason (if you respond at all). But anyway, that’s another can of worms.
Do you want bells and whistles, or do you want flexibility? If you want your testing to just get out of your way and let you concentrate on building things…
I guess I’m unclear what is so “flexible” about Tape. It appears to have a small handful of assertions, not much control over its output, doesn’t allow organization of large suites via nesting, stuff other people have written in the notes, etc.
Perhaps you’ve read this article, and now you’re using Tape, and you see that a setup() might be useful. You can hand-roll that yourself as you have above; I suppose that’s flexibility? Of course, if you’re in the business of writing your own test hook framework, maybe you should unit test that too. Or just use a framework which comes with those “bells & whistles” already unit tested for you.
I’ve seen Tape used on small projects, where it appears successful. When things get complex, I’d probably reach for a more powerful tool. I understand its appeal, however. I’m curious to know if anyone writes functional tests with Tape, and what speed bumps they may have encountered.