【Angular × Cypress】一覧画面テストを最速で作る方法と自動生成戦略（モック設計まで完全解説）

 

はじめに

Angular で構築された業務アプリに対して Cypress でテストを書く場合、

  • テストを書くのが遅い

  • APIモックの扱いに悩む

  • 画面変更でテストが壊れやすい

といった課題にぶつかることが多いです。

特に一覧画面は数が多く、
毎回ゼロからテストを書くのは非効率です。

そこで本記事では、

  • 最速でテストを書く設計

  • APIモックの使い分け

  • テストコードの自動生成戦略

を実務ベースでまとめます。

結論（先に）

最も現実的で強い構成はこれです。

テストの分け方

種類 内容 API
主力テスト 表示・分岐確認 モック
接続確認テスト 実際の疎通確認 実通信
ハイブリッド 一部だけ固定 部分モック

開発スタイル

  • data-testid を必ず付与

  • 一覧画面はテンプレ化

  • screen.yaml → テスト生成

  • APIは cy.intercept() で制御

なぜこの構成が最強か

  • テストが速い

  • 壊れにくい

  • 実環境の確認もできる

  • 自動生成と相性が良い

1. なぜビジュアルテストを捨てるべきか

一覧画面では、見た目はよく変わります。

  • デザイン変更

  • レイアウト変更

  • カラム順変更

これらをビジュアルテストで追うと

👉 正しいのに落ちるテストが大量発生

代わりに見るべきもの

✔ 表示値

  • 件数

  • ステータス

  • 合計値

✔ 動き

  • 検索

  • ページ遷移

  • ボタン動作

✔ API連携

  • 正しいリクエスト

  • 正しいレスポンス反映

👉 結論

「見た目」ではなく「意味」をテストする

2. CypressでのAPIモック戦略

基本は cy.intercept()

cy.intercept('GET', '/api/users', {
  fixture: 'users.json'
}).as('getUsers');

① 全部モック（主力テスト）

beforeEach(() => {
  cy.intercept('GET', '/api/users', { fixture: 'users.json' });
});

目的

  • 表示確認

  • 分岐確認

  • エラー確認

メリット

  • 速い

  • 安定する

② 一部だけモック（実務で一番使う）

cy.intercept('GET', '/api/users', { fixture: 'users.json' });

👉 他のAPIは実通信

例

  • 一覧だけ固定

  • 詳細は実API

③ モックしない（疎通確認）

cy.visit('/users');

目的

  • API接続確認

  • 本番に近い動作確認

④ 実通信しつつ検証

cy.intercept('GET', '/api/users', (req) => {
  expect(req.query.name).to.eq('田中');
  req.continue();
});

👉 通信はそのまま、本当に呼ばれたか確認

3. テスト設計（超重要）

悪い例

  • 全部モック

  • 全部実通信

良い設計

主力テスト（80%）

  • 一覧表示

  • 検索

  • エラー

  • 0件

👉 モック

サブテスト（20%）

  • ログイン

  • 遷移

  • 保存

👉 実通信

理由

項目 モック 実通信
速度 ◎ △
安定性 ◎ △
現実性 △ ◎

👉 バランスが重要

4. data-testid戦略

なぜ必要か

CSSやテキストは壊れやすい

推奨ルール

<input data-testid="search-name-input" />
<button data-testid="search-button">検索</button>
<tr data-testid="user-row"></tr>

命名テンプレ

種類 例
ページ page
入力 search-name-input
ボタン search-button
行 user-row
エラー error-message

👉 これだけで自動化が楽になる

5. テスト自動生成戦略

ここが本記事の核心です。

基本アイデア

screen.yaml
   ↓
Node.js
   ↓
Cypressテスト生成

screen.yaml例

name: user-list
route: /users

api:
  list: /api/users

selectors:
  row: user-row
  searchInput: search-name-input

tests:
  - init-load
  - search
  - empty
  - error

生成されるもの

  • E2Eテスト

  • Componentテスト

  • fixture

メリット

  • 10画面でも一瞬

  • 書き方が統一される

  • 人的ミスが減る

6. 実務で最強の構成

フォルダ構成

screen.yaml
tools/generator.js

cypress/
  e2e/
  fixtures/

src/app/
  component.cy.ts

流れ

① yamlを書く
② コマンド実行
③ テスト生成
④ 必要な部分だけ修正

ポイント

👉 全部自動にしない

7. 自動化の限界と現実解

自動化できるもの

  • テンプレート

  • APIモック

  • fixture

  • 基本テストケース

人がやるべきもの

  • 業務ロジック

  • エッジケース

  • メッセージ確認

  • UX的な検証

👉 重要

自動化 = 補助ツール

8. おすすめの最終構成

開発フロー

  1. Angularに data-testid 追加

  2. screen.yamlを書く

  3. テスト自動生成

  4. 必要な部分だけ修正

  5. CIで実行

テスト構成

user-list.stub.cy.ts   ← メイン
user-list.real.cy.ts   ← 接続確認

ポイント

  • モックと実通信を分ける

  • テストの目的を明確にする

まとめ

最重要ポイント

  • 見た目ではなく「値」と「動き」をテストする

  • APIモックは「全部 or 一部 or なし」を使い分ける

  • data-testid は必須

  • 一覧画面はテンプレ化できる

  • テストは自動生成 + 手修正が最強

一言でいうと

👉 「テストを作る」のではなく「テストを量産できる仕組みを作る」