Upgrade to Pro — share decks privately, control downloads, hide ads and more …

コドモンにおけるAPIテストを紹介するno / Introducing API testing...

コドモンにおけるAPIテストを紹介するno / Introducing API testing in CoDMON

More Decks by コドモン開発チーム

Transcript

  1. 4 • 名前 すなかわ / ミジンコおじさん (X: koppamijinko) • 経歴 2014

    〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 • 好きなテスト技法 デシジョンテーブルテスト
  2. 8 導入施設数推移(ICT) 2021年4月 8,000 2020年4月 5,200 2019年4月 3,000 2018年4月 1,500

    2017年4月 500 2016年4月 120 全国導入数 18,000 施設 2022年2月 11,000 18,000 2024年3月 (2024年3月時点) 14,000 2023年4月
  3. 価値 • コミュニケーション • シンプルさ • フィードバック • 勇気 •

    リスペクト 原則 • 人間性:みんなが自分らしくいられるチームで • ふりかえり:起きたことから学んで、再現性を  ハンドリング • ベイビーステップ:小さく始める、小さく進める                    など プラクティス • 受け入れテスト • 持続可能なペース • TDD • ペアプログラミング         など 価値・原則を意識しながらプラクティスを実行することで、「価値を体現できている状態」へ 開発手法 XP(エクストリーム・プログラミング)に則り、 アジャイルなチームを目指す 9
  4. 18 コドモンの開発とテスト • コドモンでは アジャイル開発・XP を取り入れている ◦ TDDや受入テスト、CI/CD など品質を上げながら開発を進める •

    開発する機能がユーザーストーリーとして書かれている ◦ 開発を始める時に受入条件を満たすテストを一番最初に書く ▪ フロントエンド×サーバーサイドの場合は、E2Eテスト ▪ サーバーサイドの実装だけの場合は、APIテスト
  5. 19 バグフィルターに基づくテストの配分 • Unit Test は、Domain層や UseCase層の機能の正常系やエ ラーのテスト • E2E

    Test は、ハッピーパス+ どうしてもE2Eの方がやりやす いテスト • Integration Test(APIテスト) で、コンポーネント結合時の機 能性担保のための網羅的なテス トを厚くする
  6. 21 バグフィルターに基づくテストの配分 • Unit Test ◦ Domain層やUseCase層が設計通りに動いているか確認するテスト ◦ 例:連絡帳のデータ生成、連絡帳の送信処理 など

    • E2E Test ◦ ハッピーパス+どうしてもE2Eの方がやりやすいテスト ◦ 例:保護者アプリにログイン後、連絡帳の送信する • Integration Test(APIテスト) ◦ コンポーネント結合時の機能性担保を目的とした網羅的なテスト ◦ 例:連絡帳APIの認証、連絡帳の送信 など
  7. 22 テストを一部紹介 • Spec • GETのAPI ◦ Status Code ◦

    Body部分の値 • エラーコードもチェック # 認証のAPI ## 保護者は認証されたユーザーの情報を取得できる * 保護者アカウントにID"[email protected]"とパスワー ド"password1234"でログインする * 保護者APIの"/parent-api/me"にGETリクエストする * レスポンスのステータスコードが "200"であること * レスポンスの"userName"が"大泉洋"であること * レスポンスの"facilityName"が"どうでしょうゼミナール "であること ## 保護者はログインしていない場合 401が返却される * APIの"/parent-api/me"にGETリクエストする(未認証) * レスポンスのステータスコードが "401"であること
  8. 23 テストを一部紹介 • Spec • POST / PUT のAPI ◦

    アプリが送信して くるBodyのjson を指定する ◦ jsonの中のデータ を変えながら網羅 性を上げる ◦ DB のAssert も実 施 # 保護者の連絡帳送信 APIのテスト ## 保護者は、施設に連絡帳を送信できる * 保護者アカウントに ID"[email protected]"とパスワード"password1234"でログインできる * 連絡帳APIの"/contact-api/v1/parents/send"にBody"/test1.json"でPOSTリクエストする * レスポンスのステータスコードが "200"であること * "contacts"テーブルで以下の通りになっているレコードが "1"件あること | column | value | |------------------------|----------------------------------------------------------| | contact_id | 7219880f-1c0a-46ac-b46f-3012337e586b | | message | 一生どうでしょうします | ## 保護者は、連絡欄に 1001文字を入れたら、APIは400を返す * 保護者アカウントに ID"[email protected]"とパスワード"password1234"でログインできる * 連絡帳アプリAPIの"/contact-api/v1/parents/send"にBody"/test2.json"でPOSTリクエストする * レスポンスのステータスコードが "400"であること
  9. 26 gauge によるAPIテストのメリット • Markdown で仕様を書くことができる ◦ 開発チケットをストーリー単位で管理していることが多い ◦ 自由度の高い記述でストーリー達成のための受入テストを作る

    ことができる • gauge の step を汎用的に書いておくことで、step の再利用が可能 ◦ APIのレスポンス(Status Code, Body) ◦ DBに格納されたデータ ◦ localstack のSQS に格納されたメッセージ など
  10. 27 前提条件の準備 • コドモンでは、テスト実行前にテスト対象のAPIサーバーの 周辺システムをSetupする仕組みを入れている ◦ DB ◦ WireMock サーバー

    ◦ localstack • Context Step という概念があるので、それでDBのデータセットや Wire MockのSetup をしています!
  11. 28 前提条件のSetup class ContextSteps { # DBのconfig val dbConfig =

    DatabaseConfiguration( Environment.DbUrl, Environment.DbUser, Environment.DbPassword ) # WiremockのSetup private val setUpWireMock = SetUpWireMock() # Datasetsの一覧 private val dataSets: List<DataSet> = listOf( ReadDataSet4000, CreateDataSet4001 ) @BeforeSuite fun beforeSuite() { # DBのSetup    ・    ・ # WireMockのSetup    ・    ・ }
  12. 29 テストの実行方法 • 下記タイミングで実施 ◦ 開発途中にローカル環境で実施 ◦ 下記タイミングで自動テストを実施 ▪ Push時

    ▪ スケジュール ▪ デプロイ前 • 常にAPIレベルでの機能性担保を行った状態で、開発を続けること ができる!
  13. 30 • コドモンの開発では、開発時にテストを作ることが多い ◦ Unit Test, Integration Test, E2E Test

    それぞれの責務を考え て、テストを作る • Integration Test では、コンポーネント結合時の機能性担保を中心 に考えているので、ストーリー達成のためのテストをMarkdownで 書ける gauge は相性◎ • テストを便利にする仕組みと組み合わせることで、APIテストをよ り深く考えることができる! ◦ Context Step ◦ 自動テストできる状態にしておく まとめ
  14. WEBアプリケーションエンジニア • プロダクトの価値向上のための開発 ◦ 新規開発や機能改善 ◦ リファクタリング ◦ 開発生産性向上 •

    機能単位のリプレイス開発 QAエンジニア • 品質保証戦略の策定 • 品質に関する知識・技術の普及推進 • ソースコード品質向上のためのCI/CDパイプライン構築 • テスト設計・実装 エンジニアリングマネージャー • 採用・評価運用の改善の推進 • 開発ロードマップの議論の推進 • 開発部全体のプロセス改善の推進 • 自己組織化の促進 やることの例 やることの例 やることの例 34 色々な職種・役割において仲間を募集中です 採用ページは 右のQRコードから ご確認下さい👉