Nickolay Platonov
13 February 2019

Writing isomorphic tests with Siesta 5.2.0

We recently released a minor 5.2.0 version and in this blog post we will walk through the new features in […]

We recently released a minor 5.2.0 version and in this blog post we will walk through the new features in Siesta. Along with the usual minor improvements and bug fixes, the new release brings seamless support for writing tests as ECMAScript 6 modules in Node.js. No additional configuration is needed, you just write regular code. Note that in browsers you still need to explicitly indicate that a test is an ECMA module with the isEcmaModule config.

It is enough to specify this config once at the project level, and then the code of the tests can be exactly the same in browsers and Node.js. This is only relevant for tests that exercise the code using only the ECMA spec features for modules. Normally this just means that you need to use a relative url instead of the absolute one (assuming you don’t write your CSS files as JavaScript modules).

For example, in the server-side Node.js environment, you would normally write:

import {SomeThing} from "some"
import {AnotherThing} from "another/module/file.js"

But you can write the full relative url to the module file in “node_modules” folder instead (including the file extension):

import {SomeThing} from "../../node_modules/some/index.js"
import {AnotherThing} from "../../another/module/file.js"

Such code runs perfectly in both the browser and in a Node.js process. It is sometimes called “isomorphic”, meaning that the code is very abstract and generic and does not rely on the implementation details of the execution environment (no DOM or process), only on the ECMAScript specification.

The obvious advantage of such approach is that there’s no need for using Webpack, which enables quick prototyping where you can easily switch between browser and Node.js environments. You can always add an optimised Webpack build later, when the code really needs to be optimised (first it has be written of course). There is really no reason to not use this approach for any abstract, cross-platform code, like data manipulation for example.

The main reason behind the success of JavaScript, was that code could be executed in the browser platform, on the client side. Later, the Node.js platform emerged but it failed to deliver simple code sharing between the client and server. And finally, we have it. I think, this is a major milestone for the language. And I really encourage all of you to use it, please consider writing your next hobby or job project as an “isomorphic” NPM module.

A sample project written in this approach (including tests) can be found here: This is an open-source implementation of a reactive, graph-based computational engine, which will be powering the scheduling logic in the upcoming Bryntum Gantt 1.0 release.

You can clone it, do npm install and either run in console:

npx siesta ./tests

(npx is a binary, that comes with Node.js and launches files from the ./node_modules/.bin folder in a cross-platform way), or open the https://localhost/yourpath/chronograph/tests/index.html in the browser. The results will be the same.

Running tests in the browser:

Running exactly same test in Node.js:

We hope you will write your next test isomorphically, happy testing!

Nickolay Platonov