Chapter 9. Having Confidence in Your Visualizations

When you're building things for the huge audience the Web allows, a very real fear that you have is a software glitch that prevents data from displaying correctly. When developing projects on a tight timeline, testing is an aspect that often gets neglected as the deadline gets closer and closer, and often things need to be viewed by other people (editors, managers, and the like) even earlier, emphasizing output over process in turn. Let me be clear--if you want to ensure that your visualizations are high-quality, you need to take steps to ensure that they are well-tested and functioning properly. On some level, doing this is an exercise in managing complexity.

The following chart depicts project complexity over time. As you can see, complexity increases somewhat exponentially as time goes on. Adding more team members, more lines of code, and/or more dependencies increases the project's complexity dramatically. Meanwhile, the step-chart depicts...

Linting everything!

A linter is a piece of software that runs source code through a set of rules and then causes a stink if your code breaks any of those rules. On the one hand, this is intended to make code look consistent across a project, but on another, it flags up potential code issues while developing--particularly obvious mistakes, such as misnamed variables.

Linting rules are often based on industry best practices, and most open source projects have a customized ruleset corresponding to their community guidelines. This simultaneously ensures that code looks consistent even when delivered by a multitude of people, and also lets contributors know when they're doing something that's a little confusing or error-prone in their code. Note, however, that all of these rules are just opinions; you don't have to write your code following them, but it tends to help everyone else out if you do.

If you've been following along with the GitHub repo for this book, perhaps you've noticed a hidden file...

Static type checking: TypeScript versus Tern.js

Static type checking is where you have a process that looks at how variables are being used, and then throws a wobbly if you do something weird. By this, I mean it looks at the type of each variable and uses either type annotations (bits of text defining what type a variable is when the variable itself is defined) or type inference (figuring out what the type is from how you first used it) to ensure that functions don't mutate a variable in an unexpected way. This is called static typing and is a feature built into many robust languages, such as C++ and Java. While JavaScript's dynamic typing (also shared by lots of other web languages, such as PHP and Ruby) is helpful in some ways and enables a certain style of programming, it can also be incredibly frustrating due to its ability to introduce silent errors. As we're using a transpiler to transform our JavaScript anyway (throughout the book this has been Babel, though many other transpilers...

Behavior-driven development with Mocha and Chai

All of these will get you pretty far toward, with more confidence in your visualizations, but another step you can take to be even more of a rockstar is to add automated testing to your projects.

There are many reasons to write automated tests: if you have a product that has to reliably render charts, and the chart is rendering merely a part of a much larger application, you likely want to use automated testing to ensure that changes to the application don't break your charts. Likewise, if you've created an open source project that receives a lot of pull requests from various people who use your library, you might want tests to ensure that none of this outside code causes regressive bugs. Beyond that, automated tests are great if you want to be able to show your editor proof that your chart is working and accurate, or if you merely want to have more confidence in your data visualization work.

There are fundamentally two ways you can approach...

Summary

This chapter was all about tooling. We started with linting using ESLint, then moved up to static typing using TypeScript, then finished with some testing in Mocha. That's a lot of ground to cover! Don't feel bad if you're a bit overwhelmed by it all right now, this was meant to be a really shallow overview of these tools and how to use them with D3. There are lots of resources you can pursue now that you know the basics; I highly recommended reading a little more about testing because that's really probably the biggest and most important of all of them.

We will close this book by looking at some particularly impressive examples of data visualization. Don't worry, we're done with coding now; sit back, relax, and enjoy the show as we take a quick look at what makes for a quality data visualization.