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
1k
フロントエンドテストのためのMSW
【オンライン】エンジニア達の「〇〇完全に理解した」Talk #27 で話した内容です。
https://easy2.connpass.com/event/241509/
Hirorou
March 31, 2022
Tweet
Share
Other Decks in Programming
See All in Programming
コンテナでLambdaをデプロイするときに知っておきたかったこと
_takahash
0
130
Day0 初心者向けワークショップ実践!ソフトウェアテストの第一歩
satohiroyuki
0
330
AtCoder Heuristic First-step Vol.1 講義スライド(山登り法・焼きなまし法編)
takumi152
3
950
WordPress Playground for Developers
iambherulal
0
120
なぜselectはselectではないのか
taiyow
2
280
生産性アップのためのAI個人活用
kunoyasu
0
470
Scala 3 で GLSL のための c-like-for を実装してみた
exoego
1
180
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
0
320
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.3k
php-fpm がリクエスト処理する仕組みを追う / Tracing-How-php-fpm-Handles-Requests
shin1x1
4
780
PHPのガベージコレクションを深掘りしよう
rinchoku
0
240
PHPによる"非"構造化プログラミング入門 -本当に熱いスパゲティコードを求めて- #phperkaigi
o0h
PRO
0
1.1k
Featured
See All Featured
A better future with KSS
kneath
238
17k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Six Lessons from altMBA
skipperchong
27
3.7k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Gamification - CAS2011
davidbonilla
80
5.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
134
33k
It's Worth the Effort
3n
184
28k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.6k
Making Projects Easy
brettharned
116
6.1k
Statistics for Hackers
jakevdp
797
220k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
22
2.6k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
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