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 testing: you can build your project and add testing after the fact, possibly needing to refactor parts so that it's more easily testable, or you can write your tests at the very beginning of your project, before any code, and then build your project, ensuring that it passes the tests you've created at each step of the way.
The latter approach is called Test-Driven Development (TDD), and should be seen as the hallmark of having reached some degree of skill with JavaScript. An extension of that is called Behavior-Driven Development (BDD), which tends to be more focused on user interface interactions. BDD tests tend to be less brittle as they focus more on how a feature is functioning than how it works.
I personally find the syntax of BDD-style testing frameworks nicer to read and write, and that's what I'll use here, via the Chai library.
There are several types of automated test you can do, but we will mainly focus on unit and functional testing.
Unit testing is when you test each of your project's functions in an isolated fashion, which requires you to write your code in such a way that side-effects are minimized. If you remember from Chapter 4, Making Data Useful, one aim of functional programming is to not have your functions produce side-effects, and unit tests are a way of both ensuring and verifying that this is in fact the case. TDD focuses on writing unit tests for each part of your application as part of the initial development process; you're simultaneously quality-assuring your code as you write it.
Functional testing, on the other hand, is more comparable to looking at how the application behaves in a consumer context. Imagine that you buy a new phone. The phone has had each of its components tested to a very high level at the factory, and that whole process is opaque to you; you assume that it passed all tests because it made it out of the factory. Comparatively, a functional test will evaluate whether you can do certain activities successfully--can you open a web browser and navigate to your favorite website? If you press the increase volume button, does the volume increase? Are you able to successfully navigate to the clock app and set an alarm for the next morning? These end-user structured workflows are what make up good functional tests.
BDD is more geared toward testing the latter, and it's particularly helpful with data visualizations. In some ways, D3 does some of the unit testing work for you; because your project is using a release of D3 that passes all of its tests (that is, the phone has left the factory), you don't need to worry so much about D3 doing anything wrong. Rather, your bigger concerns are preventing silent errors due to dynamic typing (that is, concatenating the numbers 1 and 1 as strings and getting 11 instead of adding them together to get 2) and ensuring that user manipulation of data doesn't cause errors. This is where BDD comes in.