Please support this book: buy it or donate

9. Getting started with quizzes and exercises

Throughout most chapters, there are quizzes and exercises. These are a paid feature, but a comprehensive preview is available. This chapter explains how to get started with them.

9.1. Quizzes

Installation:

• Download and unzip impatient-js-quiz.zip
  Running the quiz app:

• Open impatient-js-quiz/index.html in a web browser

• You’ll see a TOC of all the quizzes.

9.2. Exercises

9.2.1. Installing the exercises

To install the exercises:

• Download and unzip impatient-js-code.zip
• Follow the instructions in README.txt

9.2.2. Running exercises

• Exercises are referred to by path in this book.
  • For example: exercises/syntax/first_module_test.js
• Within each file:
  • The first line contains the command for running the exercise.
  • The following lines describe what you have to do.

9.3. Unit tests in JavaScript

All exercises in this book are tests that are run via the test framework Mocha. This section gives a brief introduction.

9.3.1. A typical test

Typical test code is split into two parts:

• Part 1: the code to be tested.

• Part 2: the tests for the code.
  Take, for example, the following two files:

• id.js (code to be tested)

• id_test.js (tests)

9.3.1.1. Part 1: the code

The code itself resides in id.js:

export function id(x) {
  return x;
}

The key thing here is: everything you want to test must be exported. Otherwise, the test code can’t access it.

9.3.1.2. Part 2: the tests

The tests for the code reside in id_test.js:

import {strict as assert} from 'assert'; // (A)
import {id} from './id.js'; // (B)
test('My test', () => { // (C)
  assert.equal(id('abc'), 'abc'); // (D)
});

The core of this test file is line D – an assertion: assert.equal() specifies that the expected result of id('abc') is 'abc'.

As for the other lines:

• Line A: We import the assertion library.
• Line B: We import the function to test.
• Line C: We define a test. This is done by calling the function test():
  • First parameter: the name of the test.
  • Second parameter: the test code (provided via an arrow function with zero parameters).
    To run the test, we execute the following in a command line:

npm t demos/syntax/id_test.js

The t is an abbreviation for test. That is, the long version of this command is:

npm test demos/syntax/id_test.js

9.3.2. Asynchronous tests in mocha

Writing tests for asynchronous code requires extra work: The test receives its results later and has to signal to mocha that it isn’t finished, yet, when it returns. The following subsections examine three ways of doing so.

9.3.2.1. Calling done()

A test becomes asynchronous if it has at least one parameter. That parameter is usually called done and receives a function that you call once your code is finished:

test('divideCallback', (done) => {
  divideCallback(8, 4, (error, result) => {
    if (error) {
      done(error);
    } else {
      assert.strictEqual(result, 2);
      done();
    }
  });
});

9.3.2.2. Returning a Promise

A test also becomes asynchronous if it returns a Promise. Mocha considers the test to be finished once the Promise is either fulfilled or rejected. A test is considered successful if the Promise is fulfilled and failed if the Promise is rejected.

test('dividePromise', () => {
  return dividePromise(8, 4)
  .then(result => {
    assert.strictEqual(result, 2);
  });
});

9.3.2.3. The test is an async function

Async functions always return Promises. Therefore, an async function is a convenient way of implementing an asynchronous test. The following code is equivalent to the previous example.

test('dividePromise', async () => {
  const result = await dividePromise(8, 4);
  assert.strictEqual(result, 2);
  // No explicit return necessary!
});

You don’t need to explicitly return anything: The implicitly returned undefined is used to fulfill the Promise returned by this async function. And if the test code throws an exception then the async function takes care of rejecting the returned Promise.