[Go Make Things] Organizing JavaScript tests

By rahmat hidayat

Friday, December 13, 2024

​ So far in this series, we've looked at buildless testing, an overview of testing approaches, and how to write unit tests. Today, let's talk about how to organize your tests! Split tests up When you're testing just one library, class, or chunk of code, you can keep everything in one test and one HTML file and get on just fine. But if you're working with a larger code base or testing lots of things, its a good idea to split the tests up, for a few reasons… It helps keep things organized, so you're not scrolling through one giant test file. It lets you run individual tests for just the code you're working on, speeding everything up. Tests should be easy to work with and fast to run, or you're less likely to use them! Naming conventions A common convention is for each library or class to get its own test file that includes the word test in the name. For example, the tests for our calculator.js library could be called test.calculator.js or calculator.test.js. In addition to this naming convention, many code bases put all of the test files in a /tests directory, to keep them isolated from the rest of the code. Because we're using a buildless setup here with HTML files, you might use the same naming convention for the test HTML files. Alternatively, you could include the test scripts directly inline in the HTML files, but that would potentially make it harder to run a CI process against your tests if that's something you'd like to do. Organizing assertions inside a test file Most testing libraries also provide a way for you to organize and group assertions within a test file. In Mocha, the testing library we're using in this series, that's the describe() method. You pass in a string that describes what's about to run, and then a callback function to run some code. describe('the add() method', function () { // The tests... }); Our calculator.js library includes four methods: add(), subtract(), multiply(), and divide(). We might use describe() to group the tests for each of these methods… describe('the add() method', function () { it('Should add two or more numbers together', function () { expect(add(4, 6, 8)).to.equal(18); }); it('Should return the original value when one number is provided', function () { expect(add(42)).to.equal(42); }); it('Should return 0 if no numbers are provided', function () { expect(add()).to.equal(0); }); }); You can also nest one describe() inside another, allowing you to group all of tests for a library together… describe('The calculator.js library', function () { describe('the add() method', function () { // ... }); describe('the subtract() method', function () { // ... }); describe('the multiply() method', function () { // ... }); describe('the divide() method', function () { // ... }); }); When the test runs, it generates headings and subheadings that make the test output easier to read. If you were to run your tests using the command line, you would see a similar structure and output in the Terminal UI. What's next? You can download the source code for this tutorial on GitHub. Tomorrow, we'll look at TDD and how we can use it write better code, faster. And next week, we'll talk about code coverage, implementation details, and why neither of them really matter. We'll also look at some ways to test DOM manipulation libraries. Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+