davearonson

Test coverage of plain JS, preferably w/o npm?

I’m unit-testing some JS, with Jasmine, and I’d like to check our coverage. We’re not using any front-end framework, nor much JS, so no other need to install npm, nor much additional other JS infrastructure, so we’d prefer not to. I’ve been trying to find lightweight options, and not coming up with anything, other than very clumsy dev-tools built into different browsers (and we haven’t standardized on one, and have customers that use different ones). Any ideas, if not of specific tools then at least where to look?

Most of the rest of the project is in Ruby, so gems are an option, but it’s not Rails and we definitely don’t want to drag that in as well. (It’s in Sinatra, but we may be moving away from that too, to just plain Rack. I doubt we’d go any lower-level than that though!) The only possibly-suitable thing I’ve found there is jscover, which hasn’t been updated in forever and depends strictly on such an outdated version of v8 that it’s a PITA to install it (in fact I tried for about four hours yesterday with all kinds of workarounds and failed).

Other details: I’m on a Mac, but we need it to work on Linux for most of the rest of the team. Windows not needed. NONE of us are JS wizards, I’ve got a decent handle on the language basics and some basic DOM manipulation but that’s about it, and still seem to be in the lead. We can certainly cobble pieces together with Ruby, bash scripting, maybe a few other languages, and baling wire.

2 comments

#testing /js #coverage #not-npm #ruby-but-not-rails #no-js-framework

6 1860 2

2021-03-29 00:45:36 UTC

Most Liked

iPaul

In the JavaScript ecosystem using node (or npm) is like using gems in Ruby, you need to embrace it if you want to be able to do anything significant. You can get by with a minimal npm knowledge. That being said, node and npm works the same on macOS and Linux so your dev environment will be reproducible on Linux too (or you can use Docker). I recommend Jest Getting Started · Jest.

Post #3

davearonson

Makes sense, but I’m not sure if I want to do anything “significant” in JavaScript. I am not up-to-date on it, haven’t done all that much in a very long time, am not at all a front-ender (not that that’s bad, just different), and just don’t like JavaScript, at least insofar as I know it. On the other hand, it’s pretty much a necessary evil. On the gripping hand, I’m in the process of retiring, ideally having very little to do with JS ever again. But in the meantime, my current client has some JS in need of testing, some I wrote, meaning I could put up with not-as-great tooling, but also some one of his employees wrote, and will probably continue to write, so I should set up something they can use decently well. Maybe coverage testing just won’t be part of that – or maybe we’ll get deep enough into JS and its tooling that we’ll bite the bullet and use npm. With judicious package management, maybe we can avoid having to upgrade our disks to hold the packages.