[P02] Migrating Grunt based project to Jest

Once upon a time Grunt was cool. Now better alternative exists and we should migrate there, isn’t it? I am writing this post to share my experience with migrating to Jest from Grunt. This will be the 2nd post in the series of using Ubuntu as development OS (finally).

First, Jest is an offering from Facebook, they use to test react as well as lots of other applications on their side. But, the decision for Jest shouldn’t come as a direct response of “Offered by Facebook”. Rather, it should be because of its capability to provide each component a test suite requires. This brings to another question, what a test suite require and how Jest is better than Grunt in providing those. Let’s discuss.

When we develop an application, we’re writing some code to respond to the requirement of that application. The application will respond to some real world events and data. Then while testing, we are going to mock those events and data with some pre-defined (often hardcoded) value and check whether or not those hard-coded values match. To test our applications, we need following components:

  1. Test-runner: it’ll run our tests
  2. Transpiler: which’ll convert our codes in destined types
  3. Environment: we need some instances of the actual environment where the application will run
  4. Reporting: we need coverage report of our tests.

While using Grunt, I had to use couple of “wrappers” to use the components I needed:

  • QUnit/Mocha –> Test design and execution –> Test runner
  • es6 –> Self explanatory
  • testee –> somehow integrates QUnit/Mocha with Firefox browser –> Mock actual browser instance
  • istanbul –> code coverage –> Test quality

With Jest, everything comes out of the box and you need not to use any wrapper. The biggest benefit of this is that you need not to wait for someone to write the wrapper until you can use it. It becomes immensely beneficial because your work won’t get stuck just because someone hasn’t “voluntarily” wrote a grunt package for it. Or worse, someone wrote the wrapper long ago but they haven’t upgrade it for long so now it’s not compatible with latest version of nodeJS. With Jest, you get same APIs of Mocha, you get “istanbul” code coverage and you’re sure that these will be compatible with the latest version of nodeJS. Long-term-maintenance risk of Jest is simply close to zero …

So, after I’ve decided to use Jest for the BanglaDateJS application. Here, I had my test cases in QUnit:

QUnit.test( "System date conversion", function( assert ) {
  assert.ok(new buetDateConverter().convert("Y") === '১৪২৩', "Take current system time and test");
});

Corresponding code in Jest (either create a folder named __TEST__ and put your test codes there, or just name the files as example.test.js, another great feature of Jest on how to get started fast):

describe('System date conversion', () => {
 it('Current year value will match', () => {
  let currentTime = new buetDateConverter();
  expect(currentTime.convert("Y")).toBe('১৪২৫');
 });
});

Then, in order to run them, just install jest via npm install jest and inside test script, call it: test: jest --coverage

That’s it**. No other configuration required, just some copy-paste re-organization. I have migrated all my QUnit test (well, only 8!) via Jest and immensely satisfied with its performance. You can check the codes in BangladateJS#339a5dc commit in Github.

** Minor struggle: I had to use TZ=UTC jest in script because somehow the date instance wasn’t working in Ubuntu. I don’t know the root reason, but really liked the idea of fixing timezone in code to ensure uniformity across all environments. I have used VSCode as development IDE and highly recommend this to anyone working on Ubuntu.

Leave a Reply

Your email address will not be published. Required fields are marked *