2024年5月21日 Jasst nano vol.36 　株式会社コドモン　すなかわ コドモンにおけるAPIテストを紹介するno 

2 ● コドモンについて ● コドモンのテストに関して（APIテストを中心に） ● 最後に AGENDA 

自己紹介 

4 ● 名前　すなかわ / ミジンコおじさん (X: koppamijinko) ● 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン ● 趣味 野球観戦、映画、旅行 ● 好きなテスト技法 デシジョンテーブルテスト 

コドモンについて 

6 Mission 

7 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。 

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月 

価値 ● コミュニケーション ● シンプルさ ● フィードバック ● 勇気 ● リスペクト 原則 ● 人間性：みんなが自分らしくいられるチームで ● ふりかえり：起きたことから学んで、再現性を 　ハンドリング ● ベイビーステップ：小さく始める、小さく進める 　　　　　　　　　　　　　　　　　　　など プラクティス ● 受け入れテスト ● 持続可能なペース ● TDD ● ペアプログラミング 　　　　　　　　など 価値・原則を意識しながらプラクティスを実行することで、「価値を体現できている状態」へ 開発手法 XP(エクストリーム・プログラミング)に則り、 アジャイルなチームを目指す 9 

コドモンのテストに関して 

突然ですが、みなさん 

E2Eテストって好きですか？ 

私は好きではありません！ 

なぜなら、様々な要因で落ちるからです 

とはいえ、機能性担保をしたい 

なので、コドモンではできる限り、 APIテストも作るようにしています！ 

17 コドモンの開発とテスト チケット 受入条件 の作成 Integration Test(API, E2E) 作成 UnitTest 作成 実装 Test 実行 リファクタリ ング 

18 コドモンの開発とテスト ● コドモンでは アジャイル開発・XP を取り入れている ○ TDDや受入テスト、CI/CD など品質を上げながら開発を進める ● 開発する機能がユーザーストーリーとして書かれている ○ 開発を始める時に受入条件を満たすテストを一番最初に書く ■ フロントエンド×サーバーサイドの場合は、E2Eテスト ■ サーバーサイドの実装だけの場合は、APIテスト 

19 バグフィルターに基づくテストの配分 ● Unit Test は、Domain層や UseCase層の機能の正常系やエ ラーのテスト ● E2E Test は、ハッピーパス＋ どうしてもE2Eの方がやりやす いテスト ● Integration Test(APIテスト) で、コンポーネント結合時の機 能性担保のための網羅的なテス トを厚くする 

20 バグフィルターに基づくテストの配分 ● ストーリー ○ 保護者が施設に対して連絡帳を送信する 

21 バグフィルターに基づくテストの配分 ● Unit Test ○ Domain層やUseCase層が設計通りに動いているか確認するテスト ○ 例：連絡帳のデータ生成、連絡帳の送信処理 など ● E2E Test ○ ハッピーパス＋どうしてもE2Eの方がやりやすいテスト ○ 例：保護者アプリにログイン後、連絡帳の送信する ● Integration Test(APIテスト) ○ コンポーネント結合時の機能性担保を目的とした網羅的なテスト ○ 例：連絡帳APIの認証、連絡帳の送信 など 

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"であること 

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"であること 

そして、これらを可能にしているのが 

No content

26 gauge によるAPIテストのメリット ● Markdown で仕様を書くことができる ○ 開発チケットをストーリー単位で管理していることが多い ○ 自由度の高い記述でストーリー達成のための受入テストを作る ことができる ● gauge の step を汎用的に書いておくことで、step の再利用が可能 ○ APIのレスポンス(Status Code, Body) ○ DBに格納されたデータ ○ localstack のSQS に格納されたメッセージ など 

27 前提条件の準備 ● コドモンでは、テスト実行前にテスト対象のAPIサーバーの 周辺システムをSetupする仕組みを入れている ○ DB ○ WireMock サーバー ○ localstack ● Context Step という概念があるので、それでDBのデータセットや Wire MockのSetup をしています！ 

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 = listOf( ReadDataSet4000, CreateDataSet4001 ) @BeforeSuite fun beforeSuite() { # DBのSetup 　　　・ 　　　・ # WireMockのSetup 　　　・ 　　　・ } 

29 テストの実行方法 ● 下記タイミングで実施 ○ 開発途中にローカル環境で実施 ○ 下記タイミングで自動テストを実施 ■ Push時 ■ スケジュール ■ デプロイ前 ● 常にAPIレベルでの機能性担保を行った状態で、開発を続けること ができる！ 

30 ● コドモンの開発では、開発時にテストを作ることが多い ○ Unit Test, Integration Test, E2E Test それぞれの責務を考え て、テストを作る ● Integration Test では、コンポーネント結合時の機能性担保を中心 に考えているので、ストーリー達成のためのテストをMarkdownで 書ける gauge は相性◎ ● テストを便利にする仕組みと組み合わせることで、APIテストをよ り深く考えることができる！ ○ Context Step ○ 自動テストできる状態にしておく まとめ 

最後に 

32 Xやブログで情報発信中！ 

33 ピックアップブログ 

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