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

2024/05/21 JaSST nano vol.36

Transcript

1. 2024年5月21日 Jasst nano vol.36 　株式会社コドモン　すなかわ コドモンにおけるAPIテストを紹介するno
2. 2 • コドモンについて • コドモンのテストに関して（APIテストを中心に） • 最後に AGENDA
3. 自己紹介
4. 4 • 名前　すなかわ / ミジンコおじさん (X: koppamijinko) • 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 • 好きなテスト技法 デシジョンテーブルテスト
5. コドモンについて
6. 6 Mission
7. 7 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
8. 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月
9. 価値 • コミュニケーション • シンプルさ • フィードバック • 勇気 • リスペクト 原則 • 人間性：みんなが自分らしくいられるチームで • ふりかえり：起きたことから学んで、再現性を 　ハンドリング • ベイビーステップ：小さく始める、小さく進める 　　　　　　　　　　　　　　　　　　　など プラクティス • 受け入れテスト • 持続可能なペース • TDD • ペアプログラミング 　　　　　　　　など 価値・原則を意識しながらプラクティスを実行することで、「価値を体現できている状態」へ 開発手法 XP(エクストリーム・プログラミング)に則り、 アジャイルなチームを目指す 9
10. コドモンのテストに関して
11. 突然ですが、みなさん
12. E2Eテストって好きですか？
13. 私は好きではありません！
14. なぜなら、様々な要因で落ちるからです
15. とはいえ、機能性担保をしたい
16. なので、コドモンではできる限り、 APIテストも作るようにしています！
17. 17 コドモンの開発とテスト チケット 受入条件 の作成 Integration Test(API, E2E) 作成 UnitTest 作成 実装 Test 実行 リファクタリ ング
18. 18 コドモンの開発とテスト • コドモンでは アジャイル開発・XP を取り入れている ◦ TDDや受入テスト、CI/CD など品質を上げながら開発を進める • 開発する機能がユーザーストーリーとして書かれている ◦ 開発を始める時に受入条件を満たすテストを一番最初に書く ▪ フロントエンド×サーバーサイドの場合は、E2Eテスト ▪ サーバーサイドの実装だけの場合は、APIテスト
19. 19 バグフィルターに基づくテストの配分 • Unit Test は、Domain層や UseCase層の機能の正常系やエ ラーのテスト • E2E Test は、ハッピーパス＋ どうしてもE2Eの方がやりやす いテスト • Integration Test(APIテスト) で、コンポーネント結合時の機 能性担保のための網羅的なテス トを厚くする
20. 20 バグフィルターに基づくテストの配分 • ストーリー ◦ 保護者が施設に対して連絡帳を送信する
21. 21 バグフィルターに基づくテストの配分 • Unit Test ◦ Domain層やUseCase層が設計通りに動いているか確認するテスト ◦ 例：連絡帳のデータ生成、連絡帳の送信処理 など • E2E Test ◦ ハッピーパス＋どうしてもE2Eの方がやりやすいテスト ◦ 例：保護者アプリにログイン後、連絡帳の送信する • Integration Test(APIテスト) ◦ コンポーネント結合時の機能性担保を目的とした網羅的なテスト ◦ 例：連絡帳APIの認証、連絡帳の送信 など
22. 22 テストを一部紹介 • Spec • GETのAPI ◦ Status Code ◦ Body部分の値 • エラーコードもチェック # 認証のAPI ## 保護者は認証されたユーザーの情報を取得できる * 保護者アカウントにID"hogehoge@example.com"とパスワー ド"password1234"でログインする * 保護者APIの"/parent-api/me"にGETリクエストする * レスポンスのステータスコードが "200"であること * レスポンスの"userName"が"大泉洋"であること * レスポンスの"facilityName"が"どうでしょうゼミナール "であること ## 保護者はログインしていない場合 401が返却される * APIの"/parent-api/me"にGETリクエストする(未認証) * レスポンスのステータスコードが "401"であること
23. 23 テストを一部紹介 • Spec • POST / PUT のAPI ◦ アプリが送信して くるBodyのjson を指定する ◦ jsonの中のデータ を変えながら網羅 性を上げる ◦ DB のAssert も実 施 # 保護者の連絡帳送信 APIのテスト ## 保護者は、施設に連絡帳を送信できる * 保護者アカウントに ID"hogehoge@example.com"とパスワード"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"hogehoge@example.com"とパスワード"password1234"でログインできる * 連絡帳アプリAPIの"/contact-api/v1/parents/send"にBody"/test2.json"でPOSTリクエストする * レスポンスのステータスコードが "400"であること
24. そして、これらを可能にしているのが
26. 26 gauge によるAPIテストのメリット • Markdown で仕様を書くことができる ◦ 開発チケットをストーリー単位で管理していることが多い ◦ 自由度の高い記述でストーリー達成のための受入テストを作る ことができる • gauge の step を汎用的に書いておくことで、step の再利用が可能 ◦ APIのレスポンス(Status Code, Body) ◦ DBに格納されたデータ ◦ localstack のSQS に格納されたメッセージ など
27. 27 前提条件の準備 • コドモンでは、テスト実行前にテスト対象のAPIサーバーの 周辺システムをSetupする仕組みを入れている ◦ DB ◦ WireMock サーバー ◦ localstack • Context Step という概念があるので、それでDBのデータセットや Wire MockのSetup をしています！
28. 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 　　　・ 　　　・ }
29. 29 テストの実行方法 • 下記タイミングで実施 ◦ 開発途中にローカル環境で実施 ◦ 下記タイミングで自動テストを実施 ▪ Push時 ▪ スケジュール ▪ デプロイ前 • 常にAPIレベルでの機能性担保を行った状態で、開発を続けること ができる！
30. 30 • コドモンの開発では、開発時にテストを作ることが多い ◦ Unit Test, Integration Test, E2E Test それぞれの責務を考え て、テストを作る • Integration Test では、コンポーネント結合時の機能性担保を中心 に考えているので、ストーリー達成のためのテストをMarkdownで 書ける gauge は相性◎ • テストを便利にする仕組みと組み合わせることで、APIテストをよ り深く考えることができる！ ◦ Context Step ◦ 自動テストできる状態にしておく まとめ
31. 最後に
32. 32 Xやブログで情報発信中！
33. 33 ピックアップブログ
34. WEBアプリケーションエンジニア • プロダクトの価値向上のための開発 ◦ 新規開発や機能改善 ◦ リファクタリング ◦ 開発生産性向上 • 機能単位のリプレイス開発 QAエンジニア • 品質保証戦略の策定 • 品質に関する知識・技術の普及推進 • ソースコード品質向上のためのCI/CDパイプライン構築 • テスト設計・実装 エンジニアリングマネージャー • 採用・評価運用の改善の推進 • 開発ロードマップの議論の推進 • 開発部全体のプロセス改善の推進 • 自己組織化の促進 やることの例 やることの例 やることの例 34 色々な職種・役割において仲間を募集中です 採用ページは 右のQRコードから ご確認下さい👉