Jarrod Overson is a JavaScript Engineer at Shape Security in Mountain View, California. He stopped by the PubNub HQ at last week’s SF JavaScript Meetup to discuss “JavaScript Testing: Idiot Proofing Your Code” aka Achieving Maintainability. In his entertaining talk, Jarrod suggests testing best practices for linting, reducing complexity and unit testing.
His full talk can be seen in the video below. If you want to keep reading about JavaScript testing, scroll past the video:
JavaScript Testing Overview
Linting
How many people Lint? JSHint and ESLint have high configurability. Know your linter’s options. The whole goal around these tools is to get it to check your code against the way you want to write it. Set your limits, such as maxparams or maxdepth.
Reduce Cyclomatic Complexity
This term relatively common in the C# world, also known as conditional complexity. Technically, it’s the number of paths through a block of code; it measures how hard your code is to test. For example, every block starts off with a complexity of one. As you start adding branches, your complexity increases. Code coverage visualizations such as Istanbul can provide data of what code is covered by the tests.
Make Unit Testing Easy
How many people actually test their code? One common complaint is the complexity of testing. However, unit testing is significantly easier now, thanks to Karma, Grunt and Gulp plugins. If testing isn’t easy and automatic, it won’t get done. And if it doesn’t get visualized, it doesn’t really matter.
Build first. Set up your build before you start writing code. Most developers will use minification, which is one step of a build process. Yeoman can help you manage file copies, conflicts, and it’s easily configurable with defaults.
There are upwards of 2,400 grunt plugins, so there is no excuse to have anything manual right now. Anything you have manual will make your project very difficult to maintain, especially by somebody other than yourself, or even you a few months down the line!
Enforce Code Style
We all have our own code style guidelines. Do people go through the effort of establishing a code style in their company? Sure, but do you enforce it? There’s no point in you spending your time complaining about something that should be automated. The code style, metrics, build tools, directory structure… agree on these points, and document them. Fork the AirBNB Style Guide. Once you’ve agreed, enforce the agreement. Don’t ignore warnings — warnings are errors. Make it hard to be wrong. When anything gets pushed, have it run through all the tests and linters.
Testing at PubNub
At PubNub, we thoroughly test our SDKs, including our JavaScript SDK. We use
- We configure a GitHub hook to ping Jenkins whenever a build is pushed to Staging.
- Jenkins starts a new build upon the push.
- Mocha tests are run. Assuming these tests succeed, we proceed to step 4.
- Jenkins creates a job on testswarm to execute Qunit tests across various browsers. Cross-browser testing is done via BrowserStack. A script runs on the server which keeps querying testswarm for the swarm state . The state defines which browsers are required by swarm. This script then spawns those browsers on BrowserStack. The browsers not required any more are killed. This way whenever a job is submitted, the script will start browsres and kill them once done.
- The job creation script keeps polling swarm for test results. If the results indicate success, the build status is set as passed… if the tests indicate failure, build status is set as failure, and mail is sent to PubNub support for further investigation.