In 2016, Venkat Subramaniam wrote an incredible book called ‘Test-Driving JavaScript Applications’ which, along with JavaScript tools such as Mocha, Istanbul, Prettier and Eslint, have made me fall in love with JavaScript and Node.js (well for UI development anyway). JavaScript isn’t a proper language, right? For a long time I argued not, because the tools weren’t available to develop software with unit tests, static analysis and code coverage. This has changed and now I’m starting to take JavaScript seriously, even beyond jazzing up a web based UI. I’m almost over the lack of static typing. I’m currently using Express.js, a web framework for Node.js, a lot and Venkat includes a section on testing Express.js routes in his book. They’re a bit like controllers in the Modal View Controllers pattern: router.get(‘/’, function(req, res, next) { task.all(function(err, tasks) { res.send(tasks); }); }); Venkat’s example test looks like this: it(‘should register uri / for get’, function(done) { // … var registeredCallback = router.get.firstCall.args[1]; registeredCallback(req, res); }); I’ve left out some mocking and other boilerplate for brevity and so that we can concentrate on the one bit I don’t like. Venkat describes the test in full detail in his book. Take another look at this line: var registeredCallback = router.get.firstCall.args[1]; What it does is get the second argument for the first get route declared with the router. That’s what is returned by firstCall, the first declared route. So if there is more than one get route declared with the router and at some point you change the order in which they are declared or you declare another get route in-between, the test will break. It’s brittle. In fact it’s worse. To get the second get route you’d use secondCall and so on. So although it’s probably a very large number, there are a finite number of get routes you can get from the router with this method. For me this rang alarm bells. Google suggested this is the way that everyone is doing it. It appears to be the standard practice. It doesn’t sit at all well with me. I’d much rather be able to look up route in the router by its path. After a while printing all sorts of things to the console to find out the data structures, I was able to develop this: var rh = { findGet: function(router, path) { for (var i = 0; i < router.get.args.length; i++) if (router.get.args[i][0] === path) return router.get.args[i]; return null; }, // .. }; module.exports = { execGet: function(router, path, req, res) { var get = rh.findGet(router, path); if (get != null) get[1](req, res); }, // .. }; The findGet function takes a router and the path to test and returns all of the arguments declared for that route or null if it’s not found. The execGet function uses those arguments to execute the route, meaning that the test now becomes: it(‘should register uri / for get’, function(done) { // … execGet(router, ‘/’, req, res); }); Which is not only far more expressive, but less brittle and less code per test. It means that the declaration order of the routes for the router no longer matters. Of course similar functions can be added to facilitate testing post, put and delete. I wanted to write this up as I couldn’t find any other solution with Google. Hopefully it will encourage developers to write more tests for Express routes as they become easier and less brittle. Click here to read the blog on our site.
