Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンドテストのためのMSW
Search
Hirorou
March 31, 2022
Programming
0
1.1k
フロントエンドテストのためのMSW
【オンライン】エンジニア達の「〇〇完全に理解した」Talk #27 で話した内容です。
https://easy2.connpass.com/event/241509/
Hirorou
March 31, 2022
Tweet
Share
Other Decks in Programming
See All in Programming
AtCoder Conference 2025
shindannin
0
1k
今こそ知るべき耐量子計算機暗号(PQC)入門 / PQC: What You Need to Know Now
mackey0225
3
370
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
190
AIエージェントの設計で注意するべきポイント6選
har1101
7
3.4k
カスタマーサクセス業務を変革したヘルススコアの実現と学び
_hummer0724
0
530
CSC307 Lecture 01
javiergs
PRO
0
680
[KNOTS 2026登壇資料]AIで拡張‧交差する プロダクト開発のプロセス および携わるメンバーの役割
hisatake
0
240
Patterns of Patterns
denyspoltorak
0
1.3k
Architectural Extensions
denyspoltorak
0
270
公共交通オープンデータ × モバイルUX 複雑な運行情報を 『直感』に変換する技術
tinykitten
PRO
0
210
なぜSQLはAIぽく見えるのか/why does SQL look AI like
florets1
0
440
AI前提で考えるiOSアプリのモダナイズ設計
yuukiw00w
0
220
Featured
See All Featured
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
65
Information Architects: The Missing Link in Design Systems
soysaucechin
0
760
Marketing to machines
jonoalderson
1
4.6k
Odyssey Design
rkendrick25
PRO
1
490
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
61
52k
From π to Pie charts
rasagy
0
120
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
61
49k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.1k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
280
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
220
Transcript
フロントエンドテストのためのMSW (Mock Service Worker)
目次 • 前提 • 背景 • 開発環境要件と解決策 • 課題 •
新たな開発環境要件と解決策 • MSWの利点と懸念点 • 今後
前提 • MSWについて、完全に理解した(20%)の気持ちで話します。 • 今回出てくるフロントエンド(FE)エンジニアはReactやVueなどで 開発している方を想定しています。
背景 • 機能開発を行う際に、開発者一人がAPI開発と UI開発の両方を 担当している。 • しかし、システムの規模やエンジニアの人数が将来的に大きく なることを考慮して、BE(バックエンド) とFE(フロントエンド) を分ける開発体制の準備を始めたい。
開発環境要件と解決策 • 開発環境要件 • REST APIで作成 • OpenAPI Specificationを設計書代わりに手動で記入、FEとBEに別々で開発 •
FE側は OpenAPI Specificationで設計したValidationやMockデータを使用したい • その時の解決策 • Prismの使用 • PrismとはStoplight社が提供するOSSのOpen API SpecificationをベースにしたMock Server と Validation Proxyである。 • 構築時にServerを起動する必要あり • GitHub: https://github.com/stoplightio/prism
課題 • PrismではVueやReactのためのError Objectを返却することができ なかった • →JSやTSのObjectを返却してくれるMock API環境が欲しい • そのため、FEテストでMock
APIを活用できなかった。 (Unit, Component, E2E Test) ↑私が調べた範囲内の内容です。もしかしたらPrism内で解決策はあるか もしれません。
新たな開発環境要件と解決策 • 開発環境要件 • REST APIで作成 • OpenAPI Specificationを設計書代わりに手動で記入後、FEとBEに別々で開発 •
FE側は OpenAPI Specificationで設計したValidationやMockデータを使用したい • JSやTSのObjectを返却してくれるMock API環境が欲しい (MSW以外にもこれを満たすツールはありますがMSWの公式ドキュメントのComparison読むと分かりやすいです。) • 解決策 • Mock Service Worker (MSW)の使用 (理由:去年11月頃、少し記事で見かけたため) • MSWとは Service Worker APIを活⽤して実際のRequestを仲介するMock API Library • GitHub: https://github.com/mswjs/msw • Service Worker API: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
MSWの利点と懸念点 • 利点 • TypeScriptがSupportされている • Service Workerを経由するので、 サーバー構築が必要ない •
Install後、スクリプトに記入するくらいの手間感 • スタブとは違い、ロジックも記述できるので柔軟なテストの幅が増える • API側のValidationや簡易的なビジネスロジック(Inputされるデータに応じてSuccess or Error ケースを分岐して返却) • ブラウザのNetworkタブにも反映される →公式ドキュメントのIntroductionとComparison, デモで確認 • 懸念点 • 前述で紹介した開発環境と比較 • FE側でOpen API Specificationを基に、Mock APIとValidationを作成してもらう時、 書き間違いが起こる可能性がある。 引用)h"ps://mswjs.io/
今後 • GraphQLにも対応しているので取り組みたい • GraphQLに適したMSWのコードを生成して、型推論まで行うツ ールがあるらしい • GitHub: https://www.graphql-code-generator.com/plugins/typescript-msw