Going off-road with Jasmine and node.js testing
After some consideration, I decided to throw my considerable weight (physical, not intellectual) behind Javascript/Node/Typescript/Angular for the near future. There are some things I want to build and at some point you have to pick a stack and get on with it.
But I’m opinionated. I like having my unit tests with my code, not in another tree somewhere (that may or may not have a matching directory structure). I’m not the only one. The current Angular 2+ style guide’s LIFT rules are consistent with this approach (as is the project structure the Angular CLI generates). I didn’t come up with anything as cool as LIFT though I clearly wanted what it offers.
And if you’re not an Angular fan for some reason, one of my favorite resources for node.js-related information lately is Rising Stack and in this piece on Node.js at Scale, they say:
Place your test files next to the tested modules using some kind of naming convention, like
<module_name>.spec.js… Your tests should live together with the tested modules, keeping them in sync. It would be really hard to find and maintain the tests and the corresponding functionality when the test files are completely separated from the business logic.
Tests that cross components or collateral that supports testing can go in a /tests folder or an /e2e folder (for end-to-end or integration tests). Tuck those appropriately close to the code they care about (and for).
Thing is, the more popular Javascript test frameworks that get used with node.js, namely Mocha and Jasmine, want all tests gathered under a single, top-level folder. That makes things easier for the test runner but it’s a somewhat old-school approach. Given Jasmine is the framework of choice for Angular testing, I was frustrated that I wasn’t figuring out how to bend it to my will.
Quick Aside: In case you’re not a Jasminite, Jasmine looks for a `jasmine.json` file in the default location of /spec/support (created when you jasmine init your project). In that file there is a spec_dir item that tells Jasmine where to start looking for tests. My search-fu is strong, but after several different vectors and scanning several dozen sets of top results, I couldn’t find a documented way to specify more than one directory.
Fortunately for me (maybe not him), I’m able to “share” these frustrations with my friend Ryan Graham (@rmgraham). My first thought was to just change the spec_dir to an empty string or “.” or “./” and let the project top-level folder be the starting point for locating tests. This didn’t work for me — I get “AssertionError: path must be a string”. It did work for Ryan with the undesirable side-effect of including node_modules in the search space. Since that’s not a desirable side-effect (and I didn’t see any exclusion rules in jasmine.json), we kept plugging along.
You barely have to poke Ryan and he starts digging through GitHub repos. Within minutes, he comes up with a gem:
And so genius it is! With that change, all the tests run. If you format it correctly, you can specify more than one directory and Jasmine will gather up the tests from multiple locations and run them. #hackaccomplished
Caveat emptor! I dug through some of the Jasmine repo tests and none of their tests test for this. While it works in the example cases here and in the associated GitHub repo, https://github.com/millarde/offroading-jasmine, know that you are off-road and be appropriately careful. For example, jasmine.json does include a set of inclusions for helpers and all specified directories in spec_dir would likely be searched for those. Probably not troublesome…
To make it easy for you to fact-check me and see some additional variations on this theme, see https://github.com/millarde/offroading-jasmine.
If you find this useful or even interesting, please click the little green heart and share liberally. Please chime in with other thoughts you’ve had or things you’ve tried. Happy testing! Happy Node-ing!
