Eliminate an entire category of bugs with a few simple tools

You’ve probably heard of ESLint, Prettier, and TypeScript. These are static code
analysis tools that are wildly popular in the JavaScript ecosystem. I consider
them all testing tools. Let’s take a look at each:

ESLint

ESLint is the pluggable linting utility for JavaScript. Linting is the process
of analyzing code for potential errors without actually running the code.
Consider this code:

if (!'serviceWorker' in navigator) {
  // the user's using an old browser :-(
}

Do you spot the problem? If you do, that’s great! But don’t you think it’d be
cool to not have to use your brain power to find and correct subtle bugs like
this one? I do! Make a computer do as much of my work for me as possible, please
and thank you. That’s what ESLint does for you.

Prettier

Prettier is the JavaScript code formatter. It’ll take your code however you
write it, and reformat it in a way that’s consistent and legible every time.
People often give me quizzical looks when I refer to Prettier as a testing tool.
But check this out:

const a = false
const b = false
const c = true
const d = a && b || c

What’s the value of d here? Do you know the order of operations of those
operators by heart? If you do, great! But do you trust that all the engineers on
your team know them well enough to not introduce a bug when refactoring this?

Run that code through Prettier, and this is what you get:

const a = false
const b = false
const c = true
const d = (a && b) || c

Even if you do know the order of operations, the extra parentheses — which
Prettier automatically adds when you save the file — are quite helpful. And if
you realize that’s not what you wanted, then you can add the parentheses
yourself and Prettier will leave it that way (const d = a && (b || c)).

This is one example of things Prettier does to make the intent of your code more
obvious — freeing your brain to focus on harder problems.

TypeScript

These are static type checkers for JavaScript. A static type checker adds syntax
to JavaScript to allow you to specify what data type a variable is. It can
follow that variable through the code to make sure it’s being used properly. (No
more x is not a function.)

Can you spot the bug in this code?

function getFullName(user) {
  const {
    name: {first, middle, last},
  } = user
  return [first, middle, last].filter(Boolean).join(' ')
}

getFullName({first: 'Joe', middle: 'Bud', last: 'Matthews'})

Maybe you can, maybe you can’t. Maybe your coworkers can, maybe they can’t. In
any case, wouldn’t it be cool if we had some software that could spot the issue
for us? Let’s rewrite that function to TypeScript:

type User = {
  name: {
    first: string,
    middle: string,
    last: string,
  },
}
function getFullName(user: User): string {
  const {
    name: {first, middle, last},
  } = user
  return [first, middle, last].filter(Boolean).join(' ')
}

Now if we call it like we did before, here’s what we get:

Argument of type '{ first: string; middle: string; last: string; }' is not assignable to parameter of type 'User'.
  Object literal may only specify known properties, and 'first' does not exist in type 'User'.(2345)

I like to consider type definitions with TypeScript to be a form of inline
automated tests. I strongly recommend you give it a shot if you haven’t yet.
Incremental adoption is possible with these tools (especially if you’re already
using babel, you can just start using babel-preset-typescript). Try it out on
your next feature and see what you think.

Conclusion

Static code analysis is a great way to get a significant boost of
confidence — fast, easily, and with less effort than writing unit tests for the
entire codebase. That’s why it forms the base of
the Testing Trophy 🏆. If
you’re not using these tools already, start now.