Enforcing Code Quality for Node.js

12,376 reads

@ patrickleet Patrick Lee Scott Read my story at https://patscott.io/

Using Linting, Formatting, and Unit Testing with Code Coverage to Enforce Quality Standards

Licensed from Adobe Stock Photo

reactions

If you are going to be writing code and shipping it to production, it’s important that the code is high quality.

reactions

In my last article, I showed you how to use docker-compose to leverage standardized, already existing Dockerfiles for development. The next step in getting our application ready for deployment is productionizing it.

reactions

I’m going to continue using the React/Parcel example from my earlier tutorial: Move over Next.js and Webpack!

reactions

Here is the source code: https://github.com/patrickleet/streaming-ssr-react-styled-components

reactions

I also haven’t done anything else related to getting the application “production ready”, so I’ll also talk about what is required for that, though it may take another article to finish… we’ll see how it goes. I’m ad-libbing this.

reactions

Let’s start with some quality control.

reactions

In this article we will explore Linting, Formatting, Unit Testing and Code Coverage and enforce some quality standards.

reactions

Linting & Formatting

According to Wikipedia, to “Lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.”

reactions

This means it enforces things like using spaces vs. tabs or making sure your code using semicolons consistently or not.

reactions

There are probably a bunch of linting errors in my project currently.

reactions

My goal so far has to demonstrate particular concepts and having too many sidebars about different things really takes away from the concepts at hand. Therefore I chose to forgo linting to keep the previous articles focused.

reactions

Now that it’s time to “productionize” our app, quality is of increased priority.

reactions

My preferred linter format is StandardJS, which is a very minimalist setup. But before we set that up, let’s talk about formatting as well.

reactions

Formatting is similar to linting, but less focused on syntax errors and more focused on just making the code look prettier, hence the name of the popular package prettier.

reactions

Thanks to a couple of awesome open-source contributors on Github we can use them both in one package — prettier-standard. Thanks to Adam Stankiewicz, Kent C. Dodds, Adam Garrett-Harris, and Benoit Averty!

reactions

In the past I’ve written about using husky to make sure rules are run before each commit. The prettier-standard package also recommends doing so, so let’s add prettier-standard, husky, and lint-staged now.

reactions

Configuring prettier-standard

First install the required packages:

reactions

npm i --save-dev prettier-standard@ 9.1 .1 husky lint-staged

In package.json add the following “format” script and new “lint-staged” and “husky” sections:

reactions

{ //... "scripts" : { // ... "format" : "prettier-standard 'app/**/*.js' 'app/**/*.jsx' 'server/**/*.js'" }, "lint-staged" : { "linters" : { "**/*.js" : [ "prettier-standard" , "git add" ], "**/*.jsx" : [ "prettier-standard" , "git add" ] } }, // ... }

I couldn’t get RegExp to work so without looking into the source I’m assuming it uses glob and not RegExp.

reactions

Now you can run

npm run format

pre-commit

git add

reactions

to format your code and check for linting errors. Also, any time you try to commit, husky’shook will be called, which will make sure any staged files (stages files) are properly linted before allowing them to be commited.

Let’s see how I did on the first pass.

reactions

➜ npm run format > stream-all-the-things@ 1.0 .0 format /Users/patrick.scottgroup1001.com/dev/patrickleet/open-source-metarepo/stream-all-the-things > prettier-standard 'app/**/*.js' 'app/**/*.jsx' 'server/**/*.js' app/client.js 52 ms app/imported.js 11 ms app/styles.js 7 ms app/App.jsx 11 ms app/components/Header.jsx 76 ms app/components/Page.jsx 7 ms app/pages/About.jsx 6 ms app/pages/ Error .jsx 5 ms app/pages/Home.jsx 6 ms app/pages/Loading.jsx 6 ms server/index.js 8 ms server/lib/client.js 11 ms server/lib/ssr.js 17 ms

And basically every file except

styles.js

reactions

Ignoring files for linting and formatting

had linting errors or didn’t look pretty enough!

There is one small issue which is specific to this project -

app/imported.js

reactions

is a generated file, and should be ignored by the linter.

Although is has

eslint-disabled

.prettierignore

.eslintignore

reactions

git checkout -- ./app/imported.js

at the top of the file, prettier does not know to enforce linting rules. No worries, let’s undo changes to that file, and then create afile and anfile to explicitly ignore it from being formatted on future runs.

Will undo changes to that file.

reactions

And now create

.prettierignore

.eslintignore

reactions

app/imported.js dist coverage node_modules

andwith the following lines:

Now when running

npm run format

app/imported.js

reactions

the fileremains unchanged. Not addressing this could be problematic due to the fact the file is generated.

Finally, I’ve mentioned committing should also

run npm run format

reactions

as a

pre-commit

reactions

➜ git commit -m 'feat: prettier-standard' husky > pre-commit (node v11 .6 .0 ) ↓ Stashing changes... [skipped] → No partially staged files found... ✔ Running linters...

hook. Let’s try it out.

Here’s the commit on Github.

reactions

Unit Testing and Code Coverage

As part of productionizing our application, we really should make sure our code is well-tested. Ideally, you should do this along the way, but I’m a bad person and have neglected it in this project thus far.

reactions

Let’s address that.

reactions

Installing and Configuring Jest

First, let’s install Jest for writing our unit tests.

reactions

npm i --save-dev jest babel-jest

Next, let’s add a jest config file so we configure jest to know where to find our files and be able to use pretty paths.

reactions

Add the following

jest.json

reactions

{ "roots" : [ "<rootDir>/__tests__/unit" ], "modulePaths" : [ "<rootDir>" , "/node_modules/" ], "moduleFileExtensions" : [ "js" , "jsx" ], "transform" : { "^.+\\.jsx?$" : "babel-jest" }, "transformIgnorePatterns" : [ "/node_modules/" ], "coverageThreshold" : { "global" : { "branches" : 10 , "functions" : 10 , "lines" : 10 , "statements" : 10 } }, "collectCoverage" : true , "collectCoverageFrom" : [ "**/*.{js,jsx}" ] }

file:

Alright, let’s unpack that. First, we set

roots

<rootDir>/__tests__/unit

__tests__/staging

__tests__/unit

reactions

to. I like putting staging tests inso setting the root towill allow me to do that later on.

Next, we set

modulePaths

node_modules

../../

app/*

server/*

reactions

to the root directory, and. This way in our tests instead of using relative paths likewe can just importor

The next two keys are telling jest to use babel to load our files so things like

import

reactions

will work without issues.

And finally, the last three sections define coverage settings — the minimum thresholds, all at 10%, and where to collect coverage from. In this article I just aim to get the pieces configured. In the next one I’ll increase the coverage threshold to 100% and walk through that process of getting there.

reactions

And to run, we can define a

test

package.json

BABEL_ENV

test

reactions

"scripts" : { // ... "test" : "cross-env BABEL_ENV=test jest --config jest.json" , "test:watch" : "cross-env BABEL_ENV=test jest --config jest.json --watch" }

Configuring Jest with Babel

script in our's scripts section. Because we are using babel-jest we will need to provide some babel settings as well, so we can setto, and we will address that in the next section.

First in order for the tests to work, we are going to need configure some babel settings. Add the following section in the env key of your .babelrc file:

reactions

{ "env" : { "test" : { "presets" :[ [ "@babel/preset-env" ], [ "@babel/preset-react" ], ], "plugins" : [ [ "@babel/plugin-syntax-dynamic-import" ] ] }, // ... } }

And let’s install the plugins and presets that we’ve referenced:

reactions

npm i --save-dev @babel/core @babel/preset-env @babel/preset-react @babel/plugin-syntax-dynamic- import babel-jest

We have 0% coverage currently, let’s add one test for the app, and one test for the server which should put us above our low threshold of 10%.

reactions

Testing the client side app with Enzyme

First, let’s test a file in app. We will want to shallow-render our components in app to test them. To do so, we will use

enzyme

reactions

npm i --save-dev enzyme enzyme-adapter-react -16

Enzyme has a setup step that we must add before we can use it in our tests. In our

jest.json

reactions

{ //other settings "setupTestFrameworkScriptFile" : "<rootDir>/__tests__/setup.js" }

file, add a new key:

And the setup file at

__tests__/unit/setup.js

reactions

import { configure } from 'enzyme' ; import Adapter from 'enzyme-adapter-react-16' ; configure({ adapter : new Adapter() });

Now with Enzyme configured we can create

__tests__/unit/app/pages/Home.jsx

reactions

Seems how our component is just a single function, that’s all we need to reach 100% coverage for this file.

reactions

Server side tests

import React from 'react' import { shallow } from 'enzyme' import Home from 'app/pages/Home.jsx' describe( 'app/pages/Home.jsx' , () => { it( 'renders style component' , () => { expect(Home).toBeDefined() const tree = shallow( < Home /> ) expect(tree.find('Page')).toBeDefined() expect(tree.find('Helmet').find('title').text()).toEqual('Home Page') expect(tree.find('div').text()).toEqual('Follow me at @patrickleet') expect(tree.find('div').find('a').text()).toEqual('@patrickleet') }) })

I want to test

server/index.js

reactions

but before I do, there are a couple of refactors that will make our lives a little bit easier.

Unit tests are meant to test a single unit. That means even though our app is using express, we are not testing express as part of this unit test. We are testing that our server is configured with the appropriate routes, middleware, and that listen is called to start the server. Unit Tests for express belong in the express project.

reactions

In order to only test the single unit we care about, we can use mocking to create lightweight interfaces that we can track using jest.mock. If we extract the server instantiation out of index into it’s own file, we will be able to more easily mock the server.

reactions

Create the file

server/lib/server.js

reactions

import express from 'express' export const server = express() export const serveStatic = express.static

with the following contents:

And update server/index.js like so:

reactions

import path from 'path' import log from 'llog' import { server, serveStatic } from './lib/server' import ssr from './lib/ssr' // Expose the public directory as /dist and point to the browser version server.use( '/dist/client' , serveStatic(path.resolve(process.cwd(), 'dist' , 'client' )) ) // Anything unresolved is serving the application and let // react-router do the routing! server.get( '/*' , ssr) // Check for PORT environment variable, otherwise fallback on Parcel default port const port = process.env.PORT || 1234 server.listen(port, () => { log.info( `Listening on port ${port} ...` ) })

Now in our test we can simply mock

server/lib/server.js

reactions

instead of a more complex mock of express.

Let’s create the test at

__tests__/unit/server/index.js

reactions

import 'server/index' jest.mock( 'llog' ) jest.mock( 'server/lib/server' , () => ({ server : { use : jest.fn(), get : jest.fn(), listen : jest.fn() }, serveStatic : jest.fn( () => "static/path" ) })) jest.mock( 'server/lib/ssr' ) describe( 'server/index.js' , () => { it( 'main' , () => { const { server, serveStatic } = require ( 'server/lib/server' ) expect(server.use).toBeCalledWith( '/dist/client' , "static/path" ) expect(serveStatic).toBeCalledWith( ` ${process.cwd()} /dist/client` ) expect(server.get).toBeCalledWith( '/*' , expect.any( Function )) expect(server.listen).toBeCalledWith( 1234 , expect.any( Function )) }) })

If we run the coverage now, we will notice that the coverage for

server/index.js

reactions

is not 100%. We have an anonymous function passed to listen which is difficult to get at. This calls for some minor refactoring.

Refactor the listen call to extract the anonymous function.

reactions

export const onListen = port => () => { log.info( `Listening on port ${port} ...` ) } server.listen(port, onListen(port))

Now we can easily test

onListen

reactions

Let’s add another test to our

server/index.js

reactions

import { onListen } from 'server/index' // ... describe( 'server/index.js' , () => { // ... it( 'onListen' , () => { const log = require ( 'llog' ) onListen( 4000 )() expect(log.info).toBeCalledWith( 'Listening on port 4000...' ) }) })

suite to account for it.

And with that, we have 100% coverage for

server/index.js

app/pages/Home.jsx

reactions

as well as

With our two tests we’ve managed to increase our coverage from 0% to 35–60% depending on the metric:

reactions

Current Coverage

reactions

Add testing to pre-commit hooks

reactions

Lastly, we want to only make sure that tests as a pre-commit hook as well to prevent broken tests from making it into the code, and later on, any untested code.

reactions

In

package.json

pre-commit

reactions

"pre-commit" : "lint-staged && npm run test"

changeto:

Now when someone tries to commit to the project it will enforce the coverage standards defined in your Jest config as well as making sure all the tests pass!

reactions

Conclusion

When it comes time to get your application production ready, it is imperative to enforce quality standards in an automated way. In this article I showed you how to set up and configure tools for linting and formatting your code, as well as how to configure your project for testing using enzyme and jest with enforced code coverage.

reactions

In the next part we will increase coverage to 100% before continuing on with creating a production ready Dockerfile.

reactions

As always, if you’ve found this helpful, please click and hold the clap button for up to 50 claps, follow me, and share with others!

reactions

Best,

Patrick Lee Scott

reactions

Check out the other articles in this series! This was part 3.

reactions

Tags