Jestによるユニットテストの導入は意外と簡単です。

2023/09/13に公開

はじめに

ユニットテストは、コードの個々の部分(関数やクラスなど)が期待通りに動作するかを確認するためのテストです。

これによって、コードの品質を高め、バグを早期に発見し、開発の効率を大きく向上させることができます。

Jestとは

JestとはJavaScriptとTypeScriptのテストフレームワークで、特にReactアプリケーションでのユニットテストや統合テストに広く使われています。

Facebook(現Meta)によって開発され、以下の特徴を備えた強力なテストツールとして知られています。

  • シンプルなセットアップ
  • モック機能
  • スナップショットテスト
  • カバレッジの測定
  • TypeScriptとの互換性
  • 非同期テスト

今回はJestの公式ドキュメントを参考にしながら「シンプルなセットアップ」「TypeScriptとの互換性」「カバレッジの測定」などをみていきたいと思います。

https://jestjs.io/ja/docs/getting-started

今回のゴール

まず最初にJavaScriptで関数を作成し、その関数のテストコードを作成した上でJestを使って自動テストを行います。

その後、TypeScriptで同様の自動テストができるように環境を整えていきます。

最後に、条件分岐のある関数を用いてテストコードを作成しつつカバレッジを見ていきます。

下記のようにテストのカバレッジを確認できるところまで実装していきます。

Image from Gyazo

Jestの導入

好きなフォルダを作成しJestをインストールします。

mkdir jest-unit-testing-introduction
cd jest-unit-testing-introduction
npm install --save-dev jest

package.jsonを確認するとJestが導入されていることがわかります。

package.json
{
  "devDependencies": {
    "jest": "^29.7.0"
  }
}

まずはテストをする対象となる関数を作成します。
この関数は2つの引数を受け取ってその合計を返す関数です。

sum.js
function sum(a, b) {
  return a + b;
}
module.exports = sum;

関数を作成できましたら、その関数を挙動をテストするコードを書いていきます。
12 を受け取ると 3を返すというテストです。

sum.test.js
const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

コマンドからテストを実行できるようにpackage.jsonに以下のコードを追記します。

package.json
{
+   "scripts": {
+     "test": "jest"
+   },
  "devDependencies": {
    "jest": "^29.7.0"
  }
}

すると、下記のコマンドでテストが実行されます。

npm test

下記のように1つのテストが通ったことを確認できましたらJestによるテストは完了です。

Image from Gyazo

テスト自体は意外と簡単だったかと思います。

ただ、実運用となるとこれだけでOKというわけにはいかず、ここから様々な環境でテストできるよう見ていきます。

TypeScriptのコードをテストできるようにする

TypeScriptの環境で同じようにJestを使えるよう設定していきます。

Jestの設定

まず最初に、Jestの設定ファイルを下記のコマンドで作成します。

npm init jest@latest

Image from Gyazo

作成されたファイルを開いて、JestでTypeScriptを直接使えるts-jestを設定します。

jest.config.ts
/**
 * For a detailed explanation regarding each configuration property, visit:
 * https://jestjs.io/docs/configuration
 */

import type {Config} from 'jest';

const config: Config = {
  // All imported modules in your tests should be mocked automatically
  // automock: false,

  // Stop running tests after `n` failures
  // bail: 0,

  // The directory where Jest should store its cached dependency information
  // cacheDirectory: "/private/var/folders/1d/4kmnfhkx0plcjyzd6s9_2d100000gn/T/jest_dx",

  // Automatically clear mock calls, instances, contexts and results before every test
  clearMocks: true,

  // Indicates whether the coverage information should be collected while executing the test
  // collectCoverage: false,

  // An array of glob patterns indicating a set of files for which coverage information should be collected
  // collectCoverageFrom: undefined,

  // The directory where Jest should output its coverage files
  // coverageDirectory: undefined,

  // An array of regexp pattern strings used to skip coverage collection
  // coveragePathIgnorePatterns: [
  //   "/node_modules/"
  // ],

  // Indicates which provider should be used to instrument code for coverage
  coverageProvider: "v8",

  // A list of reporter names that Jest uses when writing coverage reports
  // coverageReporters: [
  //   "json",
  //   "text",
  //   "lcov",
  //   "clover"
  // ],

  // An object that configures minimum threshold enforcement for coverage results
  // coverageThreshold: undefined,

  // A path to a custom dependency extractor
  // dependencyExtractor: undefined,

  // Make calling deprecated APIs throw helpful error messages
  // errorOnDeprecated: false,

  // The default configuration for fake timers
  // fakeTimers: {
  //   "enableGlobally": false
  // },

  // Force coverage collection from ignored files using an array of glob patterns
  // forceCoverageMatch: [],

  // A path to a module which exports an async function that is triggered once before all test suites
  // globalSetup: undefined,

  // A path to a module which exports an async function that is triggered once after all test suites
  // globalTeardown: undefined,

  // A set of global variables that need to be available in all test environments
  // globals: {},

  // The maximum amount of workers used to run your tests. Can be specified as % or a number. E.g. maxWorkers: 10% will use 10% of your CPU amount + 1 as the maximum worker number. maxWorkers: 2 will use a maximum of 2 workers.
  // maxWorkers: "50%",

  // An array of directory names to be searched recursively up from the requiring module's location
  // moduleDirectories: [
  //   "node_modules"
  // ],

  // An array of file extensions your modules use
  // moduleFileExtensions: [
  //   "js",
  //   "mjs",
  //   "cjs",
  //   "jsx",
  //   "ts",
  //   "tsx",
  //   "json",
  //   "node"
  // ],

  // A map from regular expressions to module names or to arrays of module names that allow to stub out resources with a single module
  // moduleNameMapper: {},

  // An array of regexp pattern strings, matched against all module paths before considered 'visible' to the module loader
  // modulePathIgnorePatterns: [],

  // Activates notifications for test results
  // notify: false,

  // An enum that specifies notification mode. Requires { notify: true }
  // notifyMode: "failure-change",

  // A preset that is used as a base for Jest's configuration
  preset: 'ts-jest',

  // Run tests from one or more projects
  // projects: undefined,

  // Use this configuration option to add custom reporters to Jest
  // reporters: undefined,

  // Automatically reset mock state before every test
  // resetMocks: false,

  // Reset the module registry before running each individual test
  // resetModules: false,

  // A path to a custom resolver
  // resolver: undefined,

  // Automatically restore mock state and implementation before every test
  // restoreMocks: false,

  // The root directory that Jest should scan for tests and modules within
  // rootDir: undefined,

  // A list of paths to directories that Jest should use to search for files in
  // roots: [
  //   "<rootDir>"
  // ],

  // Allows you to use a custom runner instead of Jest's default test runner
  // runner: "jest-runner",

  // The paths to modules that run some code to configure or set up the testing environment before each test
  // setupFiles: [],

  // A list of paths to modules that run some code to configure or set up the testing framework before each test
  // setupFilesAfterEnv: [],

  // The number of seconds after which a test is considered as slow and reported as such in the results.
  // slowTestThreshold: 5,

  // A list of paths to snapshot serializer modules Jest should use for snapshot testing
  // snapshotSerializers: [],

  // The test environment that will be used for testing
  testEnvironment: "node",

  // Options that will be passed to the testEnvironment
  // testEnvironmentOptions: {},

  // Adds a location field to test results
  // testLocationInResults: false,

  // The glob patterns Jest uses to detect test files
  // testMatch: [
  //   "**/__tests__/**/*.[jt]s?(x)",
  //   "**/?(*.)+(spec|test).[tj]s?(x)"
  // ],

  // An array of regexp pattern strings that are matched against all test paths, matched tests are skipped
  // testPathIgnorePatterns: [
  //   "/node_modules/"
  // ],

  // The regexp pattern or array of patterns that Jest uses to detect test files
  // testRegex: [],

  // This option allows the use of a custom results processor
  // testResultsProcessor: undefined,

  // This option allows use of a custom test runner
  // testRunner: "jest-circus/runner",

  // A map from regular expressions to paths to transformers
  // transform: undefined,

  // An array of regexp pattern strings that are matched against all source file paths, matched files will skip transformation
  // transformIgnorePatterns: [
  //   "/node_modules/",
  //   "\\.pnp\\.[^\\/]+$"
  // ],

  // An array of regexp pattern strings that are matched against all modules before the module loader will automatically return a mock for them
  // unmockedModulePathPatterns: undefined,

  // Indicates whether each individual test should be reported during the run
  // verbose: undefined,

  // An array of regexp patterns that are matched against all source file paths before re-running tests in watch mode
  // watchPathIgnorePatterns: [],

  // Whether to use watchman for file crawling
  // watchman: true,
};

export default config;

デフォルトから変更した箇所は下記2箇所です。

  preset: 'ts-jest',
  testEnvironment: "node",

必要なパッケージのインストール

TypeScriptを使うためのパッケージをまとめてインストールします。

npm install --save-dev ts-jest ts-node @types/jest typescript

インストールが完了しましたら、ファイル名を.tsに書き換えつつ、以下のようにコードを修正します。

sum.ts
- function sum(a, b) {
+ function sum(a: number, b: number) {
  return a + b;
}

- module.exports = sum;
+ export { sum }

sum.test.ts
- const sum = require('./sum');
+ import { sum } from './sum';

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

書き換えが完了しましたら、下記のコマンドでテストが実行されます。

npm test

テストケースを増やしていく

作成したテストはまだ一つでした。

少しテストを追加してみようかと思います。

sum.test.ts
import { sum } from './sum';

describe('sum', () => {
  test('adds 1 + 2 to equal 3', () => {
    expect(sum(1, 2)).toBe(3);
  });

  test('adds 1 - 1 to equal 0', () => {
    expect(sum(1, -1)).toBe(0);
  });

  test('adds 1 - 2 to equal -1', () => {
    expect(sum(1, -2)).toBe(-1);
  });
})

テストケースを1→3に増やしました。

書き換えが完了しましたら、下記のコマンドでテストが実行されます。

npm test

Image from Gyazo

先ほどと少しメッセージが変わりました。

Test Suites: テストのファイル数
Tests: テストケース数
Time: テストに要した時間

となります。

条件分岐を伴う関数の自動テスト

条件分岐を伴う関数にテストを導入するときの注意点を見ていきたいと思います。

まずはサンプルの関数を少しだけ修正します。

sum.ts
function sum(a: number, b: number) {
+   const c = a + b;
+   if (c > 10) {
+     return 10;
+   }
-   return a + b;
+   return c;
}

export { sum }

合計値が10より大きい場合は10を必ず返すような条件を入れてみました。

次に、jest.config.tsファイルを開きカバレッジを確認できるよう設定を変更します。

jest.config.ts
  // Indicates whether the coverage information should be collected while executing the test
-   // collectCoverage: false,
+   collectCoverage: true,

カバレッジとは

Jestにおけるカバレッジ(coverage)とは、テストがコードのどれくらいの範囲をカバーしているかを数値やパーセンテージで示した指標です。具体的には、テストによってどのくらいのコードが実行されたかを確認するためのもので、Jestはテストを実行しながらコードカバレッジを計測することができます。

書き換えが完了しましたら、下記のコマンドでテストが実行されます。

npm test

Image from Gyazo

カバレッジの項目

カバレッジには主に以下の4つの指標があり、それぞれ異なる観点からカバー率を示します:

  • Statements(Stms)(文)

コード内のすべての文が実行された割合を示します。文とは、let x = 5;やconsole.log(x);のような1つの処理です。

  • Branches(分岐)

条件分岐やswitch文などの、異なる分岐パスがテストで実行された割合を示します。たとえば、if文やelse文のどちらも実行されているかどうかが分岐カバレッジに影響します。

  • Functions(Funcs)(関数)

関数が実行された割合です。コード内のすべての関数がテストされているかを確認するための指標です。

  • Lines(行)

実行されたコード行の割合を示します。どの行のコードがテストで実行されているかを表します。

今回のテストを改めて振り返ると、Funcs(関数)は100%となっていますが、それ以外の指標が100%にはなっていません。

先ほどの合計値が10より大きい場合は10を必ず返すというケースをテストに含めていなかったからですね。

テストケースを1つ追加します。

sum.test.ts
+   test('adds 1 + 10 to equal 10', () => {
+     expect(sum(1, 10)).toBe(10);
+   });

このテストを実行すると、全ての指標が100%になったかと思います。

Image from Gyazo

なぜカバレッジが重要なのか?

カバレッジは、テストがどれだけのコードを網羅しているかの指標として役立ちますが、高いカバレッジ = 高品質では必ずしもありません。

ただし、カバレッジが低いと、重要なロジックや条件分岐がテストされていない可能性が高くなるため、カバレッジを確認してカバー率を高めることは、バグや意図しない動作を減らすのに役立ちます。

さいごに

実際の開発現場では新しい機能のリリースが優先でユニットテストが後回しになりがちです。

Jestのセットアップ自体は非常にシンプルですので、これを機にまだユニットテストが導入できていないプロジェクトで導入の検討が進むと幸いです。

記事に関するお問い合わせ📝

記事の内容に関するご質問、ご意見などは、下記よりお気軽にお問い合わせください。
ご質問フォームへ

技術支援などお仕事に関するお問い合わせ📄

技術支援やお仕事のご依頼に関するお問い合わせは、下記よりお気軽にお問い合わせください。
お問い合わせフォームへ