Jestテストとは｜使い方・Vitestとの違い・案件単価【Jest 30対応】

Jestとは？Metaが開発したJavaScriptテストフレームワーク

Jestとは、JavaScript・TypeScriptで書かれたコードを検証するための、オープンソースのテストフレームワークです。 2014年にFacebook（現Meta）が公開し、MITライセンスで配布されています。テストランナー・アサーション・モック・カバレッジまでを1つで提供する構成で、Node.jsのプロジェクトとReactアプリのテストで広く使われてきました。

Jest公式サイトは、設定なしで始めやすいこと、スナップショットテスト、モック機能、テストの並列実行などを主な特徴に挙げています。素のJavaScriptのプロジェクトなら設定なしで始めやすく、TypeScript・ESM・DOMのテストでは追加の設定が必要になることがあります。

Jestの基本的な特徴

実務で評価されているのは、テスト導入で詰まりがちな初期セットアップと、保守で重くなりがちなモック・並列実行の扱いを、ツール側が引き受けている設計です。

• 設定なしで起動しやすい：JavaScriptのプロジェクトであれば、追加設定なしでテストを実行できるケースが多い

• テストランナーとアサーションの統合：describe・test・expectが標準で提供され、外部ライブラリの組み合わせを最小限にできる

• モック機能：関数のモック、モジュールのモック、タイマーの制御が本体にそろっている

• スナップショットテスト：UIコンポーネントや構造化データの差分を検出できる

• 並列実行：テストファイルごとに別のワーカーで実行し、直列より時間を短縮しやすい（I/O待ちや重いセットアップがある場合は効果が小さい）

• カバレッジ計測：--coverageを付ければ、行・分岐・関数ごとのカバレッジレポートを出力できる

どれくらい使われているか

利用状況の目安として、npmの公開統計から、JestとVitestの週間ダウンロード数を同じ週（9月24〜30日）で比べました。

出典：npm（jestパッケージ）・npm（vitestパッケージ）の公開ダウンロード統計（2026年10月2日取得）。

2026年9月の時点では、VitestがJestを大きく上回っています。 ただし、ダウンロード数はCIでの自動インストールや、他のパッケージの依存として入る分も含む数字で、利用者の数や利用率ではありません。それでも、Jestも2年で2倍以上に増えており、「Vitestに置き換わって使われなくなった」と読むのは早計です。既存のReact・Next.js・Node.jsのプロジェクトでは、Jestで書かれたテストが今も動いています。

なぜ採用が広がったのか

Jestが普及した背景には、React公式が長くJestをテストツールとして紹介してきた経緯があります。Create React App（CRA）で作ったプロジェクトでは、裏側でJestが動いていました。Reactを学ぶエンジニアが最初に触れるテストツールがJestだった、という流れが採用拡大の土台です。

そのCRAは、2025年2月14日にReact公式が新規アプリ向けに非推奨とし、現在は保守モードです（React公式ブログ「Sunsetting Create React App」）。React公式は、新しいアプリにはNext.jsなどのフレームワークや、Viteなどのビルドツールを勧めています。Vite系の構成ではVitestが選ばれやすいため、新規開発でJestが選ばれる場面は以前より減っています。 一方で、CRA世代やNext.js・Node.jsの既存の資産にはJestのテストが大量に残っています。

フロントエンドエンジニアとして案件を探している人、土台となるJavaScriptやTypeScriptを学び直したい人にとって、Jestを読み書きできることは、既存プロジェクトに参画するときの実務スキルとして意味があります。

ミニFAQ：どのバージョンのJestを学べばよい？

2026年10月時点の最新はJest 30.5.2（2026年9月18日公開）です（npmのjestパッケージ）。新しく学ぶなら30系で問題ありません。参画先の現場では29系がまだ動いていることも多いため、package.jsonで実際のバージョンを確認しておきましょう。古い書籍や記事にはJest 26以前を前提にしたものも残っていて、今の設定値やCLIオプションとずれていることがあります。

Jest 30で変わった点

Jest 30は2025年6月4日に発表された、2022年8月のJest 29以来、約3年ぶりのメジャーバージョンです。 公式ブログ「Jest 30: Faster, Leaner, Better」から、実務に影響しやすい変更を整理します。

29系から上げるときは、公式の移行ガイド（Upgrading from Jest 29 to 30）を見ながら、Node.js・TypeScript・jsdomの3点を先にそろえると詰まりにくくなります。

Jestの主要機能

Jestの中核機能は、テストランナー・マッチャー・モック・スナップショット・カバレッジの5つです。単独のライブラリを組み合わせてそろえていた時代と比べ、Jest単体で完結する点が現場で評価されてきました。

テストランナー

describeでテストをグループ化し、testまたはitで個別のケースを書きます。前後の処理は、beforeAll・beforeEach・afterEach・afterAllで制御します。標準では、__tests__ディレクトリの中や、.test.js・.spec.jsで終わるファイルが自動で検出されます。現場では、testMatchやtestRegexで対象を調整しているプロジェクトもあります。

マッチャー（expect）

検証は、expect(値).toBe(期待値)の形で書きます。toBe・toEqual・toContain・toThrow・toHaveBeenCalledなど、用途別のマッチャーが多数そろっています。jest-extendedのようなコミュニティのパッケージで追加することもできます。

モック機能

Jestのモックは、現場で特に評価されている機能です。

• jest.fn()：任意の関数をモック関数に置き換える

• jest.mock()：モジュール単位で別の実装に差し替える

• jest.spyOn()：実装は残したまま、呼び出し履歴を記録する

• タイマーモック：setTimeout・setIntervalを仮想の時間で制御する

外部APIや時間に依存する処理を、安定したユニットテストとして書ける環境が標準でそろっています。

スナップショットテスト

expect(component).toMatchSnapshot()と書くと、初回の実行時に出力結果をファイルに保存し、2回目以降は前回との差分を検証します。Reactコンポーネントの出力や、構造化データの検証に使われます。

ただし、スナップショットを安易に増やすと、差分が出るたびに中身を見ずに更新する運用になりがちです。スナップショットは差分を読める小さな単位で作るのが、現場で好まれる使い方です。

コードカバレッジ計測

jest --coverageを付けるだけで、行・分岐・関数・文ごとのカバレッジレポートが出力されます。CIでしきい値を設け、下回ったらビルドを失敗にする運用がよく見られます。

ミニFAQ：カバレッジ100%は目指すべき？

100%を目標にすると、コストに見合わないテストが増えがちです。重要な業務ロジックやライブラリの層は高めに、UIの装飾やログ出力など壊れても影響の小さい層は低めに、としきい値を分けて設定する現場が多く見られます。数字より「重要な処理の流れをどう守るか」を優先するのが現実的です。

Jestのインストールと初期設定

Node.jsのバージョンと、TypeScript・Babelとの組み合わせ次第で、初期設定の難しさが変わります。最初の壁になりやすい部分なので、押さえておくと参画後の立ち上がりが早くなります。

npm・yarnでのインストール

JavaScriptのプロジェクトなら、開発用の依存として追加するだけで使い始められます。プロジェクトのルートでnpm install --save-dev jest（yarnならyarn add -D jest）を実行し、package.jsonのscriptsに "test": "jest" を加えるのが基本の構成です。2026年10月時点のJest 30.5.2では、Node.jsは18.14以上、20、22、24以上のいずれかが必要です（npmのパッケージ情報による。最新の対応範囲は公式で確認してください）。

jest.config.js・jest.config.tsの基本

設定ファイルは、JavaScript版とTypeScript版のどちらでも書けます。よく使う項目は次のとおりです。

TypeScript・Babelとの統合

TypeScriptのプロジェクトでは、ts-jestか@swc/jestがよく使われる選択肢です。ts-jestはTypeScriptとの統合がしやすく、型の情報を前提にした運用と相性があります。ただし、型チェックはCIでtsc --noEmitを別に実行する構成もよく見られます。Jestの実行だけで型の検査まで担保されるとは考えないほうが安全です。

@swc/jestは実行速度を重視しやすい選択肢で、大規模なプロジェクトのテスト時間の短縮に使われます。Babelの設定があるプロジェクトでは、Jestに同梱のbabel-jestが変換に使われます。

ESM（ECMAScript Modules）への対応は以前より改善していますが、Node.jsのバージョンや変換の構成、依存ライブラリ次第では設定で詰まることがあります。ViteとESMを前提にしたプロジェクトでは、Vitestのほうが設定で詰まりにくいと評価されることが多くなっています。

Jestの基本的な書き方

Jestのテストは、グループ化（describe）、個別のケース（test）、検証（expect）の3層で書くと、テストのレポートが読みやすくなります。

describe・test・itの使い分け

• describe：関連するテストをまとめるグループ。入れ子にできる

• test（またはit）：個別のテストケース。testは明示的、itは「it should ...」のように英文として読める

• テスト名の付け方：「条件＋期待される結果」を意識すると、失敗時のレポートがそのまま仕様書として読める

sum関数が「1と2を渡すと3を返す」かを確かめる最小のテストは、次の4つの要素で構成されます。

describeの中に複数のtestを置き、testの中でexpect(...).toBe(...)の形で検証するのが基本のパターンです。

マッチャーの種類

代表的なマッチャーを、カテゴリ別に整理します。

Jest 30では、Jest 26から非推奨だったtoThrowError・toBeCalledなどの別名マッチャーが削除されました（toThrow・toHaveBeenCalledに置き換えます）。古いテストを読むときは、削除された書き方が残っていないか確認しましょう。

非同期テスト（async・await）

async関数として書き、awaitで非同期処理の完了を待ちます。Promiseを返す処理なら、.resolves・.rejectsを使うと短く検証できます。setTimeoutなど時間に依存する処理は、jest.useFakeTimers()で仮想の時間にするのが基本です。

beforeEach・afterEach

テストごとに状態をリセットするためのフックです。DBクライアントの初期化、テスト用ファイルの作成、モックのクリアなどに使います。jest.clearAllMocks()・jest.resetAllMocks()・jest.restoreAllMocks()の使い分けは、現場で混乱しやすいポイントです。

モック・スタブの実装

Jestのモックは、フロントエンドのAPI呼び出し、バックエンドの外部サービス呼び出し、時間や乱数の制御まで幅広く使えます。

jest.fn()の基本

const mock = jest.fn(); で空のモック関数を作り、mockReturnValueやmockResolvedValueで戻り値を制御します。呼ばれた回数や引数は、mock.callsで参照できます。

jest.mock()でモジュールモック

外部のモジュール全体を別の実装に置き換えるパターンです。jest.mock('axios')のようにモジュール名を指定すると、テスト中はモックの実装に差し替わります。HTTPクライアント・DBクライアント・ファイルの読み書きなど、副作用のある依存を切り離す用途で使います。

React Testing Libraryとの連携

Reactコンポーネントのテストでは、Jest単体ではなくReact Testing Libraryと組み合わせるのが主流です。Jestがテストランナーとして動き、Testing Libraryが描画と操作を担当します。@testing-library/jest-domを入れると、DOM向けのマッチャー（toBeInTheDocumentなど）が追加されます。

ReactやNext.jsの案件で「テストも書ける」ことが求められる場合、多くはこの構成が想定されています。Next.jsの公式ドキュメントは、Jest・Vitest・Playwright・Cypressの4つについて設定手順を載せています。Vue系でも、Viteを採用したプロジェクトではVitestが選ばれやすくなっています。

UIコンポーネントを画面ごとに確認するStorybookと組み合わせる現場もあります。役割の違いはStorybookとは｜UIコンポーネント開発の基本・導入メリットを解説で整理しています。

ミニFAQ：jest.mockとjest.spyOnの使い分けは？

依存先の実装を完全に置き換えたいならjest.mock、実装は残したまま呼び出し履歴だけ確認したいならjest.spyOnを使うのが基本です。spyOnは元の実装を呼びながら記録できるので、ログ出力や監視系の検証で使い勝手がよくなります。

Jestと他のテストフレームワークの違い

JavaScriptのテストフレームワークには、JestのほかにVitest・Mocha・Jasmineなどがあります。それぞれの位置づけを整理します。

Vitestとの違い

Vitestは、Viteの設定をそのまま使えるテストフレームワークです。 Jestと互換性のあるAPIを多く採用しつつ、ESMをそのまま扱える設計が特徴です。2026年9月にはVitest 5が公開されています。

Vite系の新規プロジェクトではVitest、既存資産の多いプロジェクトではJestという分かれ方が、今の現実に近い整理です。両者の書き方はほぼ同じなので、片方を覚えればもう片方も読めます。参画先ではどちらも出てくると考え、両方を読み書きできる状態にしておくと案件の幅が広がります。

Mocha＋Chaiとの違い

Mochaはテストランナーに機能を絞った設計で、アサーションはChaiなどと組み合わせます。Node.jsのバックエンド・CLI・ライブラリで採用例が多く、組み合わせの自由度が高い反面、初期設定で判断することが増えます。Jestのように1つにまとまった構成と比べると、設定の手間がかかる傾向があります。

Jasmineとの違い

Jasmineは2010年代前半に普及した、BDD（振る舞い駆動開発）スタイルのテストフレームワークです。AngularJSの時代から使われています。describe・it・expectの基本構文はJestにも引き継がれているため、JasmineからJestへの移行は比較的しやすい部類です。新規の採用ではJestやVitestが選ばれる場面が多いものの、Angularの既存資産ではJasmineが残っていることもあります。

Playwright・Cypressとの位置づけの違い

Jestはユニットテスト・コンポーネントテストの領域、PlaywrightやCypressは実際のブラウザを操作するE2Eテストの領域、というのが基本の棲み分けです。対象のレイヤーが違うため、競合ではありません。実務では、Jestでユニット・コンポーネントを固め、PlaywrightでE2Eを補う構成がよく見られます。

他の言語では、JavaのJUnit、PythonのPytest、RubyのRSpecが同じ位置づけです。

フリーランス案件におけるJestの位置づけ

Jestは、案件の看板としてはほとんど書かれないスキルです。 ここでは、2026年10月2日時点でフリコンに掲載中の案件（募集終了を除く22,710件）の一覧カードに表示される、案件名・技術タグ・案件概要（抜粋）をすべて確認した結果をもとに整理します。単価は掲載時の募集単価の上限で、成約単価ではありません。

Jestを明記した案件は22,710件中4件

一覧カードの表示文言で見ると、案件名か概要の抜粋に「Jest」の文字がある案件は4件でした。いずれもフロントエンドエンジニアの案件で、TypeScript・Next.jsでの開発や、ReactでのAIサービス開発の一部としてJestでテストを書く形です。Vitestを明記した案件は1件でした。

案件カードの概要は短い抜粋のため、テストツール名まではほとんど書かれません。Jestは案件名で探すスキルではなく、「テストまで任せられるか」という担当範囲の中で問われるスキルと捉えるのが実態に近いでしょう。

担当範囲で見た単価の傾向

React・Vue・Next.js・TypeScript・JavaScript・Node.jsなどの語を含むJavaScript・TypeScript系の案件3,273件を、概要の書かれ方で3つに分けました。分類は案件カードの文言に含まれるキーワードで機械的に行っており、実際の担当範囲を完全に表すものではありません。

出典：フリーランス案件・求人一覧（フリコン・募集終了を除く）のカード表示をもとに当社集計（2026年10月2日取得）。

「製造〜単体テスト〜結合テスト」のように、テストが工程の一部として並ぶ案件は、上限100万円以上の比率が全体の半分以下にとどまりました。反対に、テスト設計やCI/CD、コードレビューまで任せる書き方の案件は、比率が全体の2倍以上になっています。

ただし、これは案件カードの短い抜粋をキーワードで分けた集計です。133件は多い数ではなく、職種の構成も違うため、「テスト設計」と書けば単価が上がるという因果を示すものではありません。 読み取れるのは、テストを「実施する」担当より、テストの仕組みを「設計・改善する」担当のほうが、高い帯の募集に入りやすいという傾向までです。

言語のタグで見ると、フリコンに掲載中のTypeScriptの案件は1,188件・平均単価80万円、JavaScriptの案件は1,322件・平均単価71万円でした（2026年10月2日時点・言語タグでの集計のため、上の表とは母集団が異なります）。

案件で求められるレベル感

本記事では、Jestについて案件で求められる水準を、便宜上3段階に整理します。

• 入門：既存のテストを実行・修正し、簡単なテストを追加できる

• 中級：モック・非同期テスト・React Testing Libraryを使い分け、新しいコンポーネントや関数のテストを設計できる

• 上級：何をユニットテストで守り、何をE2Eに任せるかの方針を立て、CIへの組み込みやカバレッジの運用まで担える

上の表で上限の高い帯に入りやすいのは、上級の内容を担える人です。目安としては、React・TypeScriptの実務が複数年あり、テストの方針づくりやCIの整備、コードレビューの方針の策定まで経験している層になります。

単価を体系的に上げる考え方は『フリーランスエンジニアの単価相場と単価の上げ方』で整理しています。自分の経験でどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

ミニFAQ：JestだけでE2Eテストまで書ける？

Jestは主にユニットテスト・コンポーネントテスト向けで、E2Eの主力ツールではありません。Jest＋jsdomはブラウザに近いDOM環境を再現するもので、実際のブラウザの挙動とは差があります。複数ブラウザでの確認や、複雑な操作の流れの検証はPlaywright・Cypressに寄せるのが一般的です。

ケース別解説

Jestを学ぶ優先度は、今の立ち位置と、狙う案件の性質で変わります。3つの典型的なケースに分けて整理します。

独立を検討中の会社員エンジニアの場合

会社員として働きながら独立を考えている場合、今の職場のプロジェクトでテストを書いた経験を、独立後に説明できる形で残しておくことが大切です。フリーランスの選考では「何をテストし、どう運用したか」を聞かれることが多いため、既存テストの追加・修正だけでなく、モックの方針やCIでの実行まで関わった経験があると、スキルシートに具体的に書けます。職場がVitestを使っている場合も、書き方はほぼ同じなので、Jestの現場にもそのまま持ち込めます。

独立済みでReact・Next.js案件が中心の人の場合

Reactを軸に案件を選ぶ場合、Jest＋React Testing Libraryの経験があると選考で有利になりやすく、案件によっては前提に近いこともあります。スタートアップや中堅企業のSaaS開発では、テストが整っていない状態から整備を任せたい意図で、テスト経験者を歓迎する募集が見られます。Jestが書ける前提で、CIの設計・カバレッジの運用・E2Eとの線引きまで話せると、上の表の上側の帯に入れる可能性が高まります。

バックエンド中心からフロントエンドへ広げる人の場合

PHP・Ruby・Pythonのバックエンドが中心のエンジニアがフロントエンドへ案件の幅を広げる場合、Jestはフロント側のテスト文化に慣れる入口として役立ちます。バックエンドのテスト経験がある人なら、describe・it・expectの構造は読みやすく、モックや非同期テストの考え方も移しやすい部類です。テスト駆動開発の進め方はTDD（テスト駆動開発）とは｜進め方・向く場面と現場で続けるコツで解説しています。

Jest学習で詰まりやすいポイントと対策

学習や案件参画の初期に詰まりやすい、代表的なポイントを整理します。

モックを使いすぎてテストが壊れやすくなる

モックは便利ですが、使いすぎると「実装が変わるたびにテストも書き直す」状態になります。外部APIや時間・乱数のように本当にモックすべき対象に絞り、純粋なロジックは実際の関数のまま検証すると、保守の手間を抑えやすくなります。

カバレッジ100%を目指して工数が膨らむ

カバレッジの数字は目的になりやすい指標です。100%に近づける過程で「テストのためのテスト」が増え、読みやすさと保守性が下がるケースは少なくありません。重要な処理のカバレッジを優先し、ログ出力やUIの装飾まで完全に網羅することは目指さない、という運用が現場では好まれます。

非同期テストでのタイミングの誤り

awaitやreturnの書き忘れで、テストは落ちないのに実は検証されていない、という状態になりがちです。async関数として明示的に書き、expect.assertions(n)で検証の回数を決めておくと、こうした見落としに早く気づけます。

Jest 29から30への移行でテストが落ちる

Node.jsやTypeScriptが古いままだったり、jsdomの更新でDOMの挙動が変わったりして、移行時にまとまってテストが落ちることがあります。先にNode.js・TypeScriptの版をそろえ、JestのリリースノートとJest公式ドキュメントで変更点を確認してから上げると、原因を切り分けやすくなります。

AIが書いたテストをそのまま採用する

生成AIでテストの下書きを作る現場が増えています。ただ、AIが書いたテストはカバレッジは上がっても、壊れるべきところで壊れないことがあります。境界値・エラー系・副作用のある処理は人が確認してから採用しましょう。具体的な進め方はAIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界で整理しています。

Jest学習ロードマップ（実務で使えるまで）

ゼロからJestを学んで案件で使えるようになるまでの順番です。期間は、業務でJavaScript・TypeScriptを日常的に書いている人を想定した目安です。

Phase 1：基本構文と初期設定（目安1〜3日）

• describe・test・expectの構造と、主なマッチャーの把握

• npmでのインストールと、package.jsonからの実行

• TypeScriptのプロジェクトでの、ts-jestか@swc/jestの設定

Phase 2：モック・非同期・カバレッジ（目安3〜7日）

• jest.fn・jest.mock・jest.spyOnの使い分け

• 非同期テスト（async・await、resolves・rejects）

• カバレッジレポートの読み方と、しきい値の設定

Phase 3：React Testing Libraryとの統合（目安1〜2週間）

• 描画・ユーザー操作・アサーション

• カスタムフックやContextのテスト

• スナップショットテストの適切な使いどころ

Phase 4：案件レベルの運用知識（継続）

• CI/CDでのテストの実行と、カバレッジのゲートの設計

• 既存のプロジェクトへの、後からのテスト導入の進め方

• E2Eテストとの分担の設計（Playwright・Cypressとの組み合わせ）

• Vitestへの移行や、Jestとの併用の判断

Phase 2まで終えると、既存テストの追加・修正は任せてもらいやすくなります。上の表で上限の高い帯に入るには、Phase 4の運用設計まで経験していることが求められる傾向です。

実践チェックリスト

参画前・案件開始直後に確認しておくと、Jest関連で詰まりにくい項目をまとめます。

• プロジェクトのJestのバージョン（29系か30系か）と、Node.js・TypeScriptのバージョン

• テストフレームワークがJestかVitestか、併用しているか

• TypeScriptの変換ツール（ts-jest・@swc/jest・babel-jest）の構成

• CIで実行されているテストのコマンドと、カバレッジのしきい値

• テスト環境（jsdom・node）と、対象のコードのレイヤーが合っているか

• モックの方針（どこまで実装を残し、どこから差し替えるか）の共通認識

• スナップショットテストの運用ルール（更新してよい条件・レビューの方針）

• React Testing Library・Vue Test Utilsなど、組み合わせるライブラリのバージョン

まとめ

Jestは、Vitestが伸びた今も既存のReact・Next.js・Node.jsのプロジェクトで使われ続けているテストフレームワークで、案件ではツール名よりも「テストの仕組みを設計できるか」が評価されます。

• 2026年10月時点の最新はJest 30系。Node.js・TypeScript・jsdomの要件が上がったため、29系からの移行時は先にそろえる

• npmの週間ダウンロード数はVitestがJestを上回ったが、Jestも2年で2倍以上に増えている。書き方はほぼ共通なので、両方を読める状態にしておく

• React案件では、Jest＋React Testing Libraryの組み合わせが基本

• フリコンの掲載案件では、Jestを名指しした案件は4件だけ。JavaScript・TypeScript系の案件で上限100万円以上の比率が高かったのは、テスト設計・テストコード・CI/CDまで任せる書き方の案件だった

• スキルシートには、Jestを使ったことだけでなく、テストの方針・モックの設計・CIでの運用まで書く

まずは手元のプロジェクトでdescribe・test・expectを書いて動かし、モック・非同期テスト・React Testing Libraryへ広げていくのが、現場の感覚に合った順番です。E2EはPlaywrightと組み合わせる構成も押さえておくと、フロントエンドのテストの全体像がつかみやすくなります。自分の経験で狙える単価の目安は、フリーランスエンジニア単価診断で確認できます。

参照元・一次情報：

• Jest公式サイト

• Jest公式ドキュメント（Getting Started）

• Jest 30: Faster, Leaner, Better（Jest公式ブログ）

• Jestリリースノート（GitHub）

• React Testing Library公式ドキュメント

• Vitest公式サイト