MENU

Visual StudioでJavaScript/TypeScript単体テストを実行する方法｜2026年4月更新ポイント

Visual Studio

Visual StudioでJavaScript/TypeScriptの単体テストを扱う場合、2026年4月時点で押さえるべき結論は「Test Explorerから主要フレームワークのテストを実行できるが、プロジェクト種別ごとに設定ファイル・テストルート・実行方法を正しく分ける必要がある」という点です。特にReact/Vue系の.esprojではVitest、ASP.NET Core連携ではJestまたはMochaの設定が実務上の確認ポイントになります。

2026年4月24日のMicrosoftDocs GitHub履歴では、対象ドキュメントに対して「自動挿入メタデータの削除」と「所有者情報の更新」に関するコミットが確認できます。一方で、テストフレームワークの対応範囲や基本手順そのものは大きく変わったというより、Visual Studio 2026時代の開発フローに合わせて「どこでテストを実行し、どこでCI/CDに接続するか」を再確認する価値が高い内容です。(GitHub)

目次

Visual StudioのJavaScript/TypeScript単体テストで確認すべき更新ポイント

Microsoft Learnの「Unit testing JavaScript and TypeScript in Visual Studio」は、Visual Studio内でJavaScript/TypeScriptの単体テストを作成・実行する方法を説明する公式ドキュメントです。コマンドプロンプトへ切り替えず、Visual StudioのTest Explorerからテストを扱える点が中心です。Node.jsプロジェクトとASP.NET Coreプロジェクトの両方が対象として説明されています。(Microsoft Learn)

2026年4月24日の更新を実務目線で見ると、見るべきポイントは次の3つです。

確認ポイント実務での意味注意すべき読者
.esprojとASP.NET Coreで手順が分かれるReact/Vue/AngularなどのCLIベースプロジェクトと、ASP.NET Core内のTypeScriptテストでは設定場所が異なるフロントエンド担当、フルスタック開発者
Test Explorer連携が前提IDE上で検出・実行・デバッグできるため、ローカル検証がしやすい開発チーム、QA、DevOps
vstest.consoleによる実行例があるC#テストと同じようにAzure DevOpsなどのCIに寄せやすいDevOps engineers、platform teams

重要なのは、「Visual Studioが何でも自動で解決する」と考えないことです。Test Explorerにテストを表示させるには、JavaScriptTestRoot、JavaScriptTestFramework、package.json、tsconfig.jsonの位置関係を正しくそろえる必要があります。

対応フレームワークはMocha、Jasmine、Tape、Jest、Vitest

公式ドキュメントでサポート対象として挙げられているJavaScriptテストフレームワークは、Mocha、Jasmine、Tape、Jest、Vitestです。React/Vue/Angularなどのモダンフロントエンドでは、既存のCLIやテンプレートがどのテストフレームワークを使っているかを確認してからVisual Studio側の設定を合わせるのが安全です。(Microsoft Learn)

フレームワーク向いているケースVisual Studio設定時の見方
VitestViteベースのReact/Vue、軽量で高速なテスト環境.esprojのReact/Vueでは第一候補になりやすい
Jest既存React資産、スナップショットテスト、豊富なエコシステムjest-editor-supportが必要になる点に注意
Mocha柔軟な構成、Node.js寄りのテストアサーションライブラリとの組み合わせを確認
JasmineAngular系や従来資産Angular側の標準構成と整合させる
Tapeシンプルなテスト記述チーム内で採用実績がある場合に検討

新規プロジェクトで迷う場合は、Vite/React/VueならVitest、既存のJest資産が多いならJest、ASP.NET Core内でシンプルに始めるならJestまたはMochaを選ぶと移行コストを抑えやすくなります。

CLIベースの.esprojではVitest設定が重要

Visual Studio 2022以降でサポートされるCLIベースの.esprojプロジェクトは、Test Explorerと連携できます。公式ドキュメントでは、ReactとVueの組み込みテストフレームワークは以前のJestからVitestに移っており、AngularではKarmaとJasmineが使われると説明されています。(Microsoft Learn)

React/Vueの.esprojでまず確認すべき設定は、プロジェクトファイル内の次の2つです。

<PropertyGroup>
  <JavaScriptTestRoot>src\</JavaScriptTestRoot>
  <JavaScriptTestFramework>Vitest</JavaScriptTestFramework>
</PropertyGroup>

JavaScriptTestRootは、Visual Studioがどのフォルダーからテストを探すかを指定します。src\を指定すればsrc配下、tests\を指定すればtests配下が探索対象になります。テストがTest Explorerに出ない場合、最初に疑うべきなのはテストコードそのものより、このテストルートの指定です。

.esprojでVitestを使う基本手順

手順作業確認ポイント
1.esprojを編集JavaScriptTestRootとJavaScriptTestFrameworkを設定
2npmパッケージを追加vitestをインストール
3package.jsonを編集scriptsに"test": "vitest"を追加
4テストファイルを作成例：src/App.test.tsx
5Test Explorerを開く表示されない場合はリビルド

テストファイルの最小例は次のようになります。

import { describe, it, expect } from 'vitest';

describe('sample suite', () => {
  it('returns expected value', () => {
    expect(2).toBe(2);
  });
});

この例は単純ですが、最初の動作確認には十分です。実務では、最初から複雑なUIテストを書くよりも、「Test Explorerに検出されるか」「Run Allで実行できるか」「失敗時にどの出力が出るか」を確認するための小さなテストを置く方が効率的です。

ASP.NET CoreプロジェクトではNuGet、npm、TypeScript設定を分けて考える

ASP.NET Coreプロジェクト内でJavaScript/TypeScriptの単体テストを扱う場合、.esprojとは設定の入口が変わります。公式ドキュメントでは、ASP.NET CoreプロジェクトにTypeScript、npm、単体テストのサポートを追加するために、必要なNuGetパッケージを含める手順が示されています。具体的にはMicrosoft.TypeScript.MSBuildとNpmを追加し、TypeScriptサポートはnpmのTypeScriptパッケージではなくNuGetパッケージで追加する説明になっています。(Microsoft Learn)

ASP.NET CoreでJestを使う場合の.csproj設定例は次のとおりです。

<PropertyGroup>
  <JavaScriptTestRoot>tests\</JavaScriptTestRoot>
  <JavaScriptTestFramework>Jest</JavaScriptTestFramework>
  <GenerateProgramFile>false</GenerateProgramFile>
</PropertyGroup>

Mochaを使う場合は、出力先に合わせて次のように指定する例が示されています。

<PropertyGroup>
  <JavaScriptTestRoot>wwwroot\js\tests\</JavaScriptTestRoot>
  <JavaScriptTestFramework>Mocha</JavaScriptTestFramework>
  <GenerateProgramFile>false</GenerateProgramFile>
</PropertyGroup>

ここでよくある失敗は、「テストファイルの置き場所」と「ビルド後のJavaScript出力先」を混同することです。TypeScriptのソースをtestsに置いているのか、コンパイル後のJavaScriptをwwwroot/js/testsに出しているのかで、JavaScriptTestRootの指定は変わります。

Jestを使う場合はjest-editor-supportを忘れない

公式ドキュメントでは、Jestを使用する場合、jestパッケージに加えてjest-editor-support npmパッケージが必要とされています。ASP.NET Coreの例でも、Jest向けにjest、jest-editor-support、@types/jestをdevDependenciesに追加する流れが示されています。(Microsoft Learn)

Jestで最低限確認したいpackage.jsonの例は次のとおりです。

{
  "scripts": {
    "test": "jest"
  },
  "devDependencies": {
    "@types/jest": "^29.5.8",
    "jest": "^29.7.0",
    "jest-editor-support": "^31.1.2"
  }
}

バージョンはプロジェクトの依存関係に合わせて調整が必要です。既存プロジェクトに導入する場合は、いきなり最新版へ上げるのではなく、現在のNode.js、TypeScript、既存テストランナーとの互換性を確認してから更新してください。

TypeScript設定で失敗しやすいのはoutfile

TypeScriptの単体テストがTest Explorerに表示されない場合、tsconfig.jsonのoutfile指定が原因になることがあります。公式ドキュメントでは、TypeScriptの場合、Test Explorerが単体テストを見つけられなくなるためoutfileオプションを使わないよう注意しています。一方で、outdirは利用できますが、package.jsonやtsconfig.jsonなどの構成ファイルはプロジェクトルートに置く必要があります。(Microsoft Learn)

避けたい設定は次のような形です。

{
  "compilerOptions": {
    "outfile": "wwwroot/js/app.js"
  }
}

代わりに、出力先を分ける場合はoutDirを使います。

{
  "compilerOptions": {
    "sourceMap": true,
    "target": "es5",
    "outDir": "wwwroot/js"
  },
  "include": [
    "scripts/**/*",
    "tests/**/*"
  ],
  "exclude": [
    "node_modules"
  ]
}

JestでTypeScriptテストをJavaScriptへコンパイルしたい場合は、testsフォルダーをexcludeから外す必要があります。ここを間違えると、テストファイルを書いたのにビルド対象から除外され、Visual Studio側で検出できない状態になります。

Test Explorerで実行・デバッグする流れ

Visual Studio内で単体テストを実行する場合は、Test Explorerを開き、Run Allまたは対象テストを右クリックして実行します。選択したテストは右クリックからデバッグも可能です。テストはバックグラウンドで実行され、結果はTest Explorerに反映されます。(Microsoft Learn)

実務でおすすめの確認順序は次のとおりです。

状態確認する場所対処
テストが表示されないTest Explorer、.esproj/.csproj、tsconfig.jsonリビルド、テストルート確認、outfile排除
テストは表示されるが失敗するOutputウィンドウ、npm scriptnpm test相当が通るか確認
TypeScriptのブレークポイントに止まらないsource map、出力先、デバッグ設定sourceMap確認、必要に応じてdebuggerを使用
npmノードが表示されないSolution Explorerプロジェクトのアンロード/リロード、またはpackage.json手動編集

TypeScriptのデバッグでは、通常はTypeScriptコードにブレークポイントを設定し、Test Explorerから対象テストを右クリックしてDebugを選びます。ただし、source mapを使う複雑な構成ではブレークポイントに到達しにくい場合があり、その場合はdebuggerキーワードを使う回避策が示されています。(Microsoft Learn)

CI/CDではvstest.consoleの利用も検討する

ローカルではTest Explorerで十分でも、チーム開発ではCI/CDでの再現性が重要です。公式ドキュメントでは、CLIベースの.esprojについて、通常のテストフレームワークのコマンドライン実行に加え、vstest.consoleを使う例も示されています。C#の単体テストと整合性を取りたい場合や、Azure DevOpsで実行したい場合に有効な選択肢です。(Microsoft Learn)

Visual Studio 2026系を想定した例は次の形です。

vstest.console .\MyProj.esproj /TestAdapterPath:"C:\Program Files\Microsoft Visual Studio\18\Enterprise\Common7\IDE\Extensions\Microsoft\JavaScript"

Visual Studio 2022系では、次のようなパス例が示されています。

vstest.console .\MyProj.esproj /TestAdapterPath:"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\JavaScript"

CIで使う場合は、固定パスに依存しすぎない設計が重要です。Enterprise以外のエディション、Build Tools環境、セルフホストエージェントではパスが異なる可能性があります。実務では、エージェント起動時にVisual Studioのインストールパスを解決するスクリプトを用意し、TestAdapterPathを変数化しておくと運用しやすくなります。

コードカバレッジとプロファイリングは混同しない

対象ドキュメントでは、JavaScript/TypeScript単体テストの文脈で「プロファイリングテストとコードカバレッジは現在サポートされていない」と説明されています。つまり、Visual StudioのTest ExplorerでJS/TSテストを実行できることと、同じ画面でカバレッジ計測まで完結することは同義ではありません。(Microsoft Learn)

一方、Visual Studio 2026全体のリリースノートでは、Profiler Agentのユニットテスト対応や、Code CoverageのCommunity/Professionalエディションへの拡大といったテスト関連の改善も案内されています。これはIDE全体のテスト体験を強化する流れですが、JavaScript/TypeScriptの公式手順では、テスト実行・デバッグとカバレッジ計測を分けて設計するのが安全です。(Microsoft Learn)

実務では次のように切り分けると判断しやすくなります。

目的Visual Studio内での扱い代替・補完策
テストの検出・実行Test Explorerを使うnpm script、vstest.console
TypeScriptテストのデバッグTest ExplorerからDebugsource map確認、debugger
JS/TSのカバレッジ対象ドキュメント上は非サポート扱いVitest/Jest側のcoverage機能をCIで実行
パフォーマンス検証VS 2026全体ではユニットテスト連携の強化あり対象言語・プロジェクトで利用可否を個別確認

「Visual Studio 2026でコードカバレッジが強化されたから、JS/TSテストもすべて同じように使える」と判断すると、導入時に期待値がずれます。フロントエンドのカバレッジは、JestやVitestの--coverageをCIで回す設計にしておく方が現実的です。

開発チームが今すぐ確認すべきチェックリスト

Visual StudioでJavaScript/TypeScriptの単体テストを安定運用するには、最初にプロジェクトの種類を見極める必要があります。React/Vue/AngularのCLIベースなのか、ASP.NET CoreにTypeScriptを組み込んでいるのかで設定が変わるためです。

チェック項目OKの目安
プロジェクト種別を確認した.esprojかASP.NET Coreかを把握している
テストフレームワークを決めたVitest/Jest/Mochaなどをチームで統一している
テストルートを明示したJavaScriptTestRootが実際のテスト配置と一致している
npm scriptを用意したnpm testまたは同等のコマンドで実行できる
Test Explorerで検出できるリビルド後にテスト一覧へ表示される
CIで再現できるnpm scriptまたはvstest.consoleで自動実行できる
カバレッジ方針を決めたVisual StudioではなくJest/Vitest側で計測するか決めている

特にDevOps engineersやplatform teamsは、ローカルのTest Explorerだけで完結させず、CI上で同じテストが動くかを早めに確認してください。IDE上では成功するがCIで失敗する場合、原因はVisual Studioではなく、Node.jsのバージョン、npmパッケージの復元、作業ディレクトリ、テストアダプターパスの違いにあることが多いです。

導入時に避けたい失敗パターン

Visual StudioのJS/TS単体テスト連携でつまずきやすいのは、機能不足よりも設定の不一致です。次のパターンは特に注意してください。

失敗パターン起きる問題対策
JavaScriptTestRootと実際の配置が違うTest Explorerに表示されないsrc\、tests\、出力先を再確認
tsconfig.jsonでoutfileを使うTypeScriptテストを検出できないoutDirへ変更
Jestでjest-editor-supportを入れていないIDE連携が不安定になるjestと一緒に追加
npm scriptが未設定Visual StudioやCIから実行しづらい"test"スクリプトを必ず用意
カバレッジまでVisual Studioに期待する導入後に運用設計が崩れるJest/Vitest側で計測方針を決める
CIでVisual Studioのパスを固定するエージェント差分で失敗するパスを変数化し、環境ごとに解決

この中でも、JavaScriptTestRootとtsconfig.jsonは最初に確認する価値があります。テストコードを修正する前に、Visual Studioが「どこを見ているか」を確認するだけで解決するケースが多いためです。

Visual Studio 2026時代の実務的な使い分け

Visual StudioでJavaScript/TypeScriptの単体テストを使う価値は、単にテストを実行できることではありません。C#、ASP.NET Core、TypeScript、Node.jsが混在するプロジェクトで、開発者が同じIDE上でテスト結果を確認できる点にあります。

一方で、フロントエンド専業の大規模プロジェクトでは、すべてをVisual Studioに寄せるより、npm scriptやフレームワーク標準のCLIを中心にし、Visual Studioはローカルデバッグや統合確認に使う方が自然です。

おすすめの使い分けは次のとおりです。

チーム構成おすすめ方針
ASP.NET Core + TypeScriptのフルスタック開発Visual Studio Test Explorerを積極的に使う
React/Vue中心のフロントエンド開発Vitest/JestのCLIを基準にし、Visual Studio連携は補助にする
C#テストとJS/TSテストを同じCIで回すvstest.console利用を検討する
グローバル開発チームnpm scriptを標準化し、IDE依存を下げる
platform teamが共通テンプレートを配布する.esproj/.csproj、package.json、tsconfig.jsonをテンプレート化する

Visual StudioのTest Explorerは強力ですが、チーム全員が同じIDEを使うとは限りません。グローバルチームでは、Visual Studioで動くことよりも「CLIでも同じように動くこと」を基準に設計した方が、DevOpsやオンボーディングで失敗しにくくなります。

まずやるべきこと

Visual StudioでJavaScript/TypeScriptの単体テストを導入・見直しするなら、最初に既存プロジェクトを棚卸ししてください。見るべき順番は、プロジェクト種別、テストフレームワーク、テスト配置、npm script、Test Explorer検出、CI実行の6点です。

新規のReact/Vue系.esprojなら、まずVitestで最小テストを1つ作り、Test Explorerに表示されるか確認します。ASP.NET Coreなら、Microsoft.TypeScript.MSBuildとNpm、.csproj内のJavaScriptTestRoot、tsconfig.jsonのoutDirを確認します。

2026年4月24日の更新は、ドキュメント本文に大きな新機能を追加したものというより、Visual Studio 2026環境でJS/TS単体テストを扱う際に、公式手順を改めて確認するきっかけとして捉えるのが実務的です。Test Explorerでの実行、CI/CDでの再現性、TypeScript設定の整合性をそろえれば、Visual Studio上でもチーム開発でも安定した単体テスト運用に近づけます。

Visual Studio
JavaScript 単体テスト TypeScript Visual Studio Jest Vitest

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次