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:
Idiot Proofing Your JavaScript aka Achieving Maintainability from PubNub on Vimeo.
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.
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.
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!
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.
At PubNub, we thoroughly test our SDKs, including our JavaScript SDK. We use Jenkins, Testswarm, BrowserStack, node-testswarm, and testswarm-browserstack.
