Karate+Database RiderによるAPI自動テスト導入工数をCline＋GitLab MCPを使って2割削減を目指す！ / 20251206 Kazuki Takahashi

2025/12/6 ソフトウェアテスト自動化カンファレンス2025
https://www.shiftinc.jp/event/9591/

株式会社SHIFT
アジャイル推進部DevOps推進グループ
髙橋 一生

Transcript

1. Copyright SHIFT Inc, All Rights Reserved. 2025 / Copyright SHIFT Inc, All Rights Reserved. 1 ソフトウェアテスト自動化カンファレンス2025 株式会社SHIFT ソリューション事業部 アジャイル推進部 DevOps推進グループ Takahashi Kazuki 6 12 15:00-15:30 髙橋 一生 Karate+Database Riderによる API自動テスト導入工数を Cline＋GitLab MCPを使って 2割削減を目指す！
2. 2 Copyright SHIFT Inc, All Rights Reserved. 自己紹介 髙橋一生｜Takahashi Kazuki 株式会社SHIFT アジャイル推進部 DevOps推進グループ テスト自動化アーキテクト 中小SIer→同人作家→SHIFT 主にバックエンド開発のPL/リード DevOps、AI関連の知見を吸収中 イラスト・漫画制作 ゲーム制作 エレキベース
3. Copyright SHIFT Inc, All Rights Reserved. 3 Question みなさん、APIテストの自動化で どんなツールを使っていますか？ 問い
4. Copyright SHIFT Inc, All Rights Reserved. 4 “APIテスト 自動化” で調べると 色々ヒットするが…
5. Copyright SHIFT Inc, All Rights Reserved. 5 DBテストデータの 投入や検証も含めて ケアしている事例は ほとんどない ほぼ必須のはずなのに…
6. Copyright SHIFT Inc, All Rights Reserved. 6 本日お伝えしたい点１ 「Karate × Database Riderはいいぞ」
7. Copyright SHIFT Inc, All Rights Reserved. 7 Question テスト工程のAI導入って どうやってますか？ 問い
8. Copyright SHIFT Inc, All Rights Reserved. 8 テスト工程のAI導入は 盛んに叫ばれているも のの…
9. Copyright SHIFT Inc, All Rights Reserved. 9 具体的にどうやって 導入すればいい？ TDD？仕様駆動開発？モデルが限定さ れた社内AI…
10. Copyright SHIFT Inc, All Rights Reserved. 10 本日お伝えしたい点２ 「AI導入はテストで 最も面倒な作業にフォーカス」
11. Copyright SHIFT Inc, All Rights Reserved. 11 「テストデータ作成」 0 20 40 60 80 100 120 APIテスト実施工数 工数割合（％） APIテスト実施工数 試算 テストケース/コード作成 テストデータ作成 学習コスト APIテスト全体の50～60%をデータ作成が占める
12. 12 Copyright SHIFT Inc, All Rights Reserved. 1. プロジェクト情報 2. API自動テスト＆AIエージェント導入 3. 苦労ポイント＆結果
13. 13 Copyright SHIFT Inc, All Rights Reserved. 1. プロジェクト情報 2. API自動テスト＆AIエージェント導入 3. 苦労ポイント＆結果
14. 14 Copyright SHIFT Inc, All Rights Reserved. プロジェクト情報（基本） • ウォーターフォール開発、足かけ5年のプロジェクト • クラサバ密結合システムを疎結合／レイヤードアーキテクチャに更改 • 開発手法全面近代化（テスト自動化どころかGitなども初導入） • UI/BEのユニットテストは自動化済み（Jest/JUnit。UIは一部） • 結合テストでAPIテスト自動化 ☜ イマココ 要件定義 基本設計 詳細設計 実装 ユニットテスト 結合テスト システムテスト 受入テスト 自動化中 - Karate、DatabaseRider 自動化済み - JUnit、Jest
15. 15 Copyright SHIFT Inc, All Rights Reserved. 全体開発推進 プロジェクト情報（メンバー構成） • 3-40人月、API数3桁以上、数万テストケース（ユニットテスト） • アプリケーションごとのチームと全体の開発を推進するチーム • SHIFTは全体の推進チーム内でテスト自動化の技術支援させていただく立場 • 髙橋はSHIFTの自動化アーキテクトとして参画 アプリ１開発チーム アプリ２開発チーム アプリ３開発チーム 開発リーダ PMO 全体開発推進 ※それぞれのアプリで画面とバックエンドを開発 SHIFTが参画 （高橋＋1、2名） SHIFTで全体のテスト自動化を支援
16. 16 Copyright SHIFT Inc, All Rights Reserved. 1. プロジェクト情報 2. API自動テスト＆AIエージェント導入 3. 苦労ポイント＆結果
17. 17 Copyright SHIFT Inc, All Rights Reserved. API自動テスト構成 Karate ＋ DatabaseRider サーバー本体 DB Karateモック 実行 手動 自動 （CICD等） API API 投入 アサーション API応答 テストケース実行 アサーション
18. Copyright SHIFT Inc, All Rights Reserved. 18 複数ツールを比較して、その中からKarateを選定 Karateの導入 比較項目 Karate Postman WireMock MockServer 機能面の豊富さ 一通りのア サーション 一通りのア サーション 一通りのア サーション 一通りのア サーション 効率化適正 Javaで部品化 が容易 △ 専用スクリプ ト OpenAPIでひ な形作成可 OpenAPIでひ な形作成可 使いやすさ （テスト実装） JUnit＋ Gherkin記法 GUIで操作 △ JSONのモッ ク動作定義 △ Java実装で コードが長い 使いやすさ （環境面） Java APIで自 動モック起動 △ モックは事前 起動が必要 △ モックは事前 起動が必要 △ モックは事前 起動が必要 CICD適正 Mavenで実行 △ 事前連携が必 要 △ ケースごと モック起動が難 △ ケースごと モック起動が難 API＋モック API＋モック モック モック
19. 19 Copyright SHIFT Inc, All Rights Reserved. Karateの良い所 コーディング・作業量 を減らせる モックサーバーを テストコードで制御 テスト特化の記法 （Gherkin記法） JUnit準拠
20. 20 Copyright SHIFT Inc, All Rights Reserved. JUnit準拠 • ユニットテストで培ったスキルが流用可 • JUnitフレームワーク内で動作するため学習コストが低い @Test @DisplayName("テスト１") void testNo1() throws Exception { // Act: テストシナリオ実行 final Results results = Runner.path("classpath:sample/Test.feature") .karateEnv("dev") .parallel(1); // Assert: シナリオ実行結果確認 Assertions.assertEquals(0, result.getFailCount(), results.getErrorMessages()); } テストケースごとのコードイメージ
21. 21 Copyright SHIFT Inc, All Rights Reserved. テスト特化の記法（Gherkin） • どのAPIを、どこに、どのデータで、何を確認するかが直感的にわかる記法 • Javaコードと格闘する必要なくやりたいテストに集中できる Feature: Test Background: * url testEndpointBase Scenario: testNo01 Given path 'Sample/user' And request read('requestJson/user-add.json') When method post Then status 201 テストケースごとのシナリオイメージ（前頁のテストコードから実行）
22. 22 Copyright SHIFT Inc, All Rights Reserved. モックサーバーをテストコードで制御 • 個人的MVPの機能 • モックサーバー：テスト対象サーバーから更に呼ばれるAPIのダミー受け口 • 余計な手順不要でテストコード内に起動／停止を埋め込める • シンプルにJUnit内でモックサーバーの制御が完結できる @Test @DisplayName("テスト２") void testNo2() throws Exception { // Arrange： モックサーバ起動 MockServer server; server = MockServer.feature("classpath:sample/TestMock.feature") .http([モックサーバのポート番号]) .build(); try { // テストシナリオ実行と結果確認をここに記述 } finally { // モックサーバ停止 server.stop(); } } テストコード上でのモックサーバー起動／停止イメージ
23. 23 Copyright SHIFT Inc, All Rights Reserved. コーディング・作業量を減らせる • 前述それぞれの合わせ技により余計なコード量＆作業を削減 • 面倒な設定も不要 Karate以外の場合 ×独自IFを採用しており 学習コストが高くカスタマイズ しづらい ×テストシナリオがJava/JSONで 定義しづらく長くなる ×モックサーバをテストケースごと に定義しづらく、また操作に別途 手順が必要 Karateの場合 ◦Java/JUnit準拠のため、エンジニアが 扱いやすくカスタマイズしやすい ◦テストシナリオがGherkinで テストに最適＆短く記述 ◦モックサーバをテストケースごとに 定義でき、また別途手動操作も不要
24. Copyright SHIFT Inc, All Rights Reserved. 24  Karateのように複数ツールを比較… と言いたいところだがそもそも選択肢があまりない ⚫ 個人的にAPIテストにDBテストデータ投入は必須だと思うのだがなんでだろう…  DBUnitと比較して、DatabaseRiderを選定 Database Riderの導入 比較項目 DatabaseRider DBUnit 使いやすさ （テスト実装） JUnit＋アノ テーション JUnit＋複雑 なJavaAPI実行 使いやすさ （環境面） YAMLで簡潔 な設定 △ コードでの DB接続設定） データ形式 多様な形式に 対応 △ JSON/XML 等一部形式）
25. 25 Copyright SHIFT Inc, All Rights Reserved. Database Riderの良い所 コーディング量を 減らせる テストデータは 複数形式対応 アノテーションで 制御 JUnit準拠
26. 26 Copyright SHIFT Inc, All Rights Reserved. JUnit準拠＆アノテーションで制御 • Karateテストケースにアノテーションを付加するだけ @Test @DataSet(value = "Sample/dataSet/sample.yml", strategy = SeedStrategy.INSERT, executeScriptsAfter = "Sample/executeScriptsAfter/sample-cleanup.sql" ) @ExpectedDataSet(value = "Sample/expectedDataSet/sample.yml", compareOperation = CompareOperation.CONTAINS ) @DisplayName("テスト３") void testNo3() throws Exception { // テストコード記述 } DatabaseRider記述イメージ（テストデータ挿入＆アサーション）
27. 27 Copyright SHIFT Inc, All Rights Reserved. テストデータは複数形式対応 • YAML／XML／JSON／CSV／Excel 形式に対応 • 正規表現や変数埋め込みなども対応 SAMPLE_TABLE: - USER_ID: "123" NAME: "Taro" AGE: 22 - USER_ID: "456" NAME: "Hanako" AGE: 34 テストデータ記述イメージ（YAML）
28. 28 Copyright SHIFT Inc, All Rights Reserved. コーディング量を減らせる • Karateとの親和性が高い • 余計な設定も不要（DB接続情報＋α程度。カスタマイズは可） • ただし、元はユニットテスト用であり、APIテストで使う場合若干クセが ある部分もある（特に比較が全量 or containsしかない部分） DatabaseRider以外の場合 DatabaseRiderの場合 ×複雑なJava APIコールが必要 ×コードでのDB接続定義が必要 ×使用できるデータ形式が少ない ◦アノテーション定義のみでOK ◦YAML形式での完結な設定 ◦多種多様なデータ形式に対応
29. Copyright SHIFT Inc, All Rights Reserved. 29  前述のテストツール導入を前提とした場合、どこにAIを適用するのが効果的か  テストコード自体は基本はAPIを投げて、結果をアサートする挙動がほぼすべて  ケースごとにバリエーションが多くボリュームも大きい部分はテストデータ  従って、テストデータをAIにつくらせるのが最も効果的 AIエージェントの導入 ※ケース自体の網羅は、使用できるモデルの都合上ハルシネーションの懸念が大きい点と 漏れがないかのチェックも困難であるため断念 テストコード テストデータ （DB） Karateシナリオ テストデータ （JSON） SAMPLE_TABLE: - USER_ID: "123" NAME: "Taro" AGE: 22 - USER_ID: "456" NAME: "Hanako" AGE: 34 { "userId": "123", "name": "Taro", "age": 22 } テストケースごとに定型的・ほぼ呼出のみ テストケースごとに多くのバリエーション・大きなデータ
30. 30 Copyright SHIFT Inc, All Rights Reserved. Cline + GitLab MCPの導入 • Clineとは • GitLab MCPとは 端末 VSCode + Cline GitLab MCP GitLab AIモデル AIエージェントが GitLabに直接アクセスで きるようにするツール AIモデルへのIF（ツー ル）の説明を具備 主にVSCode上で 動作し、指示に従い自ら タスクを建ててコーディ ング等を行うAIエージェ ント 顧客環境により選定 VSCode Cline AIモデル void sample { : }
31. 31 Copyright SHIFT Inc, All Rights Reserved. Cline + GitLab MCPの導入 • GitLab上のAPI仕様書／スキーマ定義に準拠したデータ作成が可能 • 量の多いテストデータのひな形やバリエーション作成に威力を発揮 ※最終的なアウトプットの人の目での確認と修正は必要 生成結果イメージ API仕様（GitLab上） データ条件 （ケース毎） { "userId": "123", "name": "Taro", "age": 22 } post: summary: サンプル tags: - Sample operationId: Sample requestBody: required: true content: application/json: schema: properties: userId: // データ定義 responses: "201": description: Created ユーザID：123 その他は任意
32. 32 Copyright SHIFT Inc, All Rights Reserved. テスト自動化工数２割削減を目指す！ • ケース毎のデータ条件は簡潔に整理 • データ条件とAPI仕様／スキーマ定義書をINPUTにケースごとのデータ作成 • サンプルアプリベースでは２割程度の工数削減が可能と試算 0 20 40 60 80 100 120 AI不使用 AI使用 工数割合（％） APIテスト実施工数 試算 テストケース/コード作成 テストデータ作成 学習コスト ２割削減
33. 33 Copyright SHIFT Inc, All Rights Reserved. 1. プロジェクト情報 2. API自動テスト＆AIエージェント導入 3. 苦労ポイント＆結果
34. Copyright SHIFT Inc, All Rights Reserved. 34 何をするにもガイドライン整備とメンバーへのレクチャーが必須 • 新しい技術群の導入になるので、入念な準備と手厚いサポートが必要 • ただ単に丸投げするのではなく、個々人へのキャッチアップ方策を検討 • サンプルを準備して、方針、設計方法、実装方法などを事細かにWeb上にガイドを残す • 開発チームに向けてのレクチャーも実施 • ここまでやっても各自のスキルとして身に着けるのは一朝一夕では難しい • 各チームで主担当を置いてのメンバーキャッチアップやトライアル期間用意 • 適宜粘り強いQ＆A対応も実施
35. Copyright SHIFT Inc, All Rights Reserved. 35 新技術への反発 • 全面的な開発技術刷新ということもあり、一部で新技術疲れのような声も • GitLabのMR（Merge Request）でのレビューより旧来のExcelでのやり方の方がいいのでは？など • 効果を丁寧に説明して、実際にやってみてと言いつづけることが大事 • また、新技術の使用をある程度強制できる体制も重要 • 上から押し付けるだけでなく現場からの要望は適宜反映 • 実際に現場で使ってみてやりづらい部分などは適宜ガイドへフィードバックする • 伴走する姿勢が一番大事
36. Copyright SHIFT Inc, All Rights Reserved. 36 やっぱりAIはあまり使ってくれない＆銀の弾丸ではない • 使ってくれるまでのハードルが高い • 使ってみたら「早いね」と分かってくれるが、所謂食わず嫌いのようなパターンも多い • 使わない理由をヒアリングし対策を打つ • モデルの都合上、結果が一定でなかったりハルシネーションの問題も • GitLab MCPを介して仕様書（インプット）を与えることで低減は出来るが、限界はある • 最初のひな形データ作成は得意だが、そこからの手修正で時間を要する • データ定義の細かい所が合わず動かしてみないと分からない • これから導入を考える方は、できるだけ最新のモデルやAIエージェントの使用がオススメ
37. Copyright SHIFT Inc, All Rights Reserved. 37 結果 0 20 40 60 80 100 120 AI不使用 AI使用 工数割合（％） APIテスト実施工数 テストケース/コード作成 テストデータ作成 学習コスト ２割削減 アプリ１ アプリ２ アプリ３ 予定通り（２割減工数） 予定通り（２割減工数） 見積もりミス等で遅れ （傷口は減らせた） ※テスト現在進行形のため確定情報ではありません 課題 • データ作成の精度が低い 対策：モデル強化 • 適用範囲が狭い（データ以外も） 対策：仕組み、DOC整備
38. Copyright SHIFT Inc, All Rights Reserved. 38 Summary • 新技術導入は使用者目線に立った粘り強い対応を • AIはターゲットを絞って導入 （モデルが限定される場合は特に） • Karate + Database Riderはいいぞ 総括
39. 39 Copyright SHIFT Inc, All Rights Reserved. 今日の話に興味を持ってくださった方へ 技術ブログでは アドベントカレンダー開催中！ 資料の公開やイベント告知は X をフォロー！ カジュアル面談も受付中！ https://x.com/shiftevolve_jp https://note.shiftinc.jp/m/m69f0a1c27f55
40. Copyright SHIFT Inc, All Rights Reserved. ご清聴ありがとうございました