テスト

はじめに 私の担当するバックエンドでは、機能を積み増す一方で、ビジネスロジックの中心である usecase 層にユニットテストがほぼ無い状態を長らく抱えていました。しかも500を超えるusecaseに、複数人で少しずつテストを足していく必要があります。この規模で一番の敵は「人によってテストの書き方がバラバラになること」です。書き方が揃わないと、レビューは毎回スタイルの指摘に追われ、テスト自体の信頼性も安定しません。 結論から言うと、次のように解決しました。 mockery v3 + testify + AAAパターンでテストの「型」を固定する 書き方一式を Claude CodeのSkills（AIエージェント向けの手順書） として固定し、人が書いてもAIが書いても同じ形に揃える カバレッジをCIで自動計測し、テスト未整備の箇所を可視化する この記事は、その具体的な実装方法と、その形に決めるまでの設計判断をまとめたものです。 前提として、このバックエンドはClean Architecture + DDDをベースにした モジュラーモノリス構成のGoサービスです（構成そのものの詳しい話はこちらの記事をご確認ください）。 対象読者 GoでClean Architecture / DDD風のレイヤード構成を採っていて、アプリケーション層のテストをこれから増やしたい方 既存コードにテストを「後から・複数人で・大量に」足す局面にいる方 mockery v3 + testifyでのモックテストの具体的な書き方の落としどころを知りたい方 この記事で得られること usecase層を「何を境界として」テストするかの考え方（ブラックボックス検証） mockery / テストデータ / 引数検証を、なぜこの形にしたか AAAパターンでの具体的な書き方（引数マッチャーの読み書き分離・output比較・エラー検証） テストデータ生成ヘルパーの設計（newTest{Type} + Optionパターン） 書き方一式をSkillとして固定し、人もAIも同じ形に揃える運用 カバレッジをCIで自動可視化する仕組み 動作確認環境 種別 バージョン Go 1.26.3 mockery v3 系 testify v1 系（mock / assert） CI CircleCI 1. 前提: usecase 層とは何か（ざっくり） アーキテクチャの詳細は本筋ではないので前提だけ。レイヤーの依存方向はおおむね次のとおりです。 adapter（HTTP ハンドラ） → scenario（クライアント別の組み立て・トランザクション境界） → usecase（アプリケーションのユースケース） ← 今回テストする層 → repository IF / service IF（インターフェース） → infra 実装（DB・外部サービス） usecase 層は「1つの業務操作」を表す層です。リポジトリやドメインサービスをインターフェース越しに呼び、入力DTO（input）を受け取って、ドメインのルールに従い加工し、出力DTO（output）を返します。DBアクセスや外部通信の具体実装には依存しないのがポイントです。 ...

本記事では、PlaywrightのE2Eテストで globalSetup と storageState を使い、ログイン状態を一度だけ取得して各テストで再利用する仕組みを解説します。 この方式により、ログインが必要なページのテストでも毎回ログイン操作を繰り返さずに済み、テスト全体を高速かつ安定的に実行できます。 この記事で得られること globalSetup＋storageStateでログインを1回だけ実行し、全テストで再利用する実装 httpOnly Cookieを含むログイン状態が保存・注入されるしくみ 実際にログインするテストとログイン済み状態から開始するテストの使い分け globalSetup内で成功・失敗それぞれのトレースを記録するデバッグ手法 背景と課題 これまで、ログインが必要な画面のリグレッション確認を、リリースのたびに手動で実施していました。 対象画面が十数件にのぼり、毎回30分以上の確認工数がかかっていたうえ、ログインを伴う操作フローは手動では見落としが起きやすく、リリース後に不具合に気づくケースもありました。 機能追加のペースが上がり、確認対象もさらに増えてきたことをきっかけに、これらの確認をE2Eテストで自動化し、リグレッションを継続的に担保することにしました。 E2Eテストを導入するうえで課題になるのが認証の扱いです。 テストごとにログイン操作を繰り返すと、テスト数に比例して実行時間が増え、さらにログイン処理自体の不安定さがテスト全体の信頼性を下げます。 そこで、ログインを一度だけ実行してセッション情報を保存し、各テストで再利用する仕組みを globalSetup と storageState で構築しました。本記事はその構成と運用方法をまとめたものです。 前提環境 本記事は以下の環境で動作を確認しています。お使いの環境に合わせて読み替えてください。 ツール バージョン Node.js 20.18.0 (LTS) @playwright/test 1.49.1 Nuxt 3.14.0 TypeScript 5.6.3 実行OS macOS 14 / Ubuntu 22.04 (CI) ファイル構成 E2E専用の構成として、関連ファイルは次のように配置します。 1 2 3 4 5 6 7 8 9 10 11 src/ ├── package.json # test:e2e スクリプトを追加 ├── playwright.e2e.config.ts # E2E専用Playwright設定 ├── .env.e2e # 認証情報（gitignore済み・各自作成） ├── playwright/ │ └── .auth/ │ └── user.json # ログイン済みCookie（gitignore対象・テスト実行時に自動生成） └── tests/ └── e2e/ ├── global-setup.ts # ログイン・storageState保存 └── auth.spec.ts # 認証フローのテスト E2E専用の設定ファイルを分ける理由 E2Eテストは実APIを呼び出し、実際にログインしてセッションを取得します。スナップショット比較やユニットテストなど他の種類のテストとは、API・認証・実行タイミングの要件が異なります。 ...

QAフェーズへの移行を機に、後回しにしていたテスト基盤を一気に整備した記録です。 同じドメインで連携する3つのNext.jsサイト（利用者向け/提供者向け/社内管理画面）を並行開発し、リリース前のQAに突入したものの、モンキーテストで予想を超えるバグが多発しました。 修正のたびに3サイト全画面を手動で再確認することになり、1サイクルあたり30分〜1時間かかりました。本来テストシナリオ作成に充てるはずだった1週間がバグ修正で埋まりました。 そこでE2Eテスト（Playwright）・コンポーネントテスト（Vitest）・本番エラー監視（Sentry）を 半日で一気に導入 しました。 この記事では、Next.js App Router + TanStack Query + MSW という構成で、ツール選定から実装・CI統合までの過程を解説します。あわせて、SSR / Turbopack固有のハマりポイントと、AIでテストを量産する際の落とし穴も共有します。 この記事で得られること Next.js App Routerで Playwright + MSW を動かすためのSSR対応パターン MSW ハンドラーを E2E と Vitest で共有する設計（モックの二重管理を防ぐ） E2E / Vitest / 手動テストの 仕分け基準（テストピラミッドの設計） Sentryを Next.js 16 + Turbopack で動かす際のハマりポイントと解決策 Sentryの 3層防御マスキング設計（SDKフック / Server-side Scrubber / Generative AI機能停止） ソースマップを Sentry にアップロードしない という運用選択肢とそのトレードオフ AIでテストを量産する際の「成功するテストしか作らない」問題と対策 動作確認環境 種別 バージョン OS macOS 15.x Node.js 24.x パッケージマネージャー pnpm 10.x Next.js 16.x（Turbopack） React 19.x @playwright/test 1.58.x vitest 4.x msw 2.x @sentry/nextjs 10.x @tanstack/react-query 5.x 1. 背景: 手動テストだけでは回らなくなった瞬間 3つのNext.jsサイト（利用者向けサイト/提供者向けサイト/社内管理画面）を約10名のチームで半年かけて並行開発しました。 ...