Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
なんとなくで書かないReact/ReduxのテストTips
Search
camcam_lemon
May 24, 2019
Programming
400
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
なんとなくで書かないReact/ReduxのテストTips
We Are JavaScripters! @32nd【初心者歓迎・LT会】の登壇資料です。
camcam_lemon
May 24, 2019
More Decks by camcam_lemon
See All by camcam_lemon
オレを実装してデザイン実装楽したい
lemon
0
89
要素のサイズを変えずに押しやすくする
lemon
0
100
iOSのキーボード入力ビューをカスタマイズする
lemon
0
340
視え方と文字の大きさ
lemon
1
470
Yarn WorkSpaces × React Nativeの環境構築
lemon
0
340
フロントエンドにおけるアーキテクチャとの向き合い方
lemon
10
5.1k
UI/UXデザイナーがデザインしてるもの
lemon
2
350
react-reduxで追加されたHooks APIの良い所と使い方
lemon
5
1.1k
ESLintで始めるTypeScriptの静的解析
lemon
8
2.2k
Other Decks in Programming
See All in Programming
新卒PdEのリアル
ryu1013
1
510
仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development
kobakei
0
130
The Good Stuff, Not the Slop: Engineering High-Quality Android Apps with Modern AI Tooling
danybony
1
260
フロントエンドUIフレームワークのこれまでとこれから
ssssota
5
2.9k
Intent as Code
shoppingjaws
6
1.1k
iOS 27でニュースアプリはどう変わる!? 〜日経電子版の新機能対応と、開発事例から〜
lynnswap
1
12k
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
450
手動確認はもう限界 〜XCUITestでCustom URL Schemeの遷移を起動種別ごとに自動テストする〜 / Testing Custom URL Schemes with XCUITest
otouto
0
330
Workers Cache を知る
syumai
0
210
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
290
AWS DevOps Agentで インシデント対応をAIに任せたい
honmarkhunt
7
3.1k
モバイル交通系ICへのチャージ実例から考える、クロスプラットフォーム開発におけるiOS実機テスト設計とCI運用
yusuga
1
540
Featured
See All Featured
Skip the Path - Find Your Career Trail
mkilby
1
240
WENDY [Excerpt]
tessaabrams
14
39k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
260
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Side Projects
sachag
456
43k
Faster Mobile Websites
deanohume
310
32k
Thoughts on Productivity
jonyablonski
76
5.4k
Marketing to machines
jonoalderson
1
5.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Transcript
なんとなくで書かない React/ReduxのテストTips We Are JavaScripters! @32nd
None
今日話すこと Fluxアーキテクチャの各層でテストを書く 指標を話します - 何を担保したいのか - 重要性の比重
React/Reduxの概要 Component Action Reducer Store Middleware Container
Component 3 Container 4 Middleware 5 Reducer 2 Action 1
アジェンダ
2 payload(+meta) 1 ActionType テスト項目は対応する - ユーザ操作、通信などアプリのインタラクション を全てトリガーしてそれを司る層 - Action
Action Actionのテストの重要性は極めて高いと 思われる(特にAction Type) 処理停止 ActionTypeの不一致 => 処理失敗 不正なStoreの混入 payloadの不一致
=> 後続の or Actionのテストが失敗することは即ちアプリのイ ンタラクションが機能していないことを意味する
Reducer アプリのStoreを生成すると共に唯一の更新層 - アプリの状態(≒UIの状態)はここに集約される - テスト項目は - 2 ActionTypeに対応したStateの更新 1
InitialState
Reducer 生成できない 不正なStateの混入 Stateの不一致 => Viewが 、 Viewが更新されない ActionTypeの不一致 =>
Reducerのテストが失敗するとアプリの状態管理 が行えずに正しいViewを返せなくなってしまう テストの重要性は高いと思われる
3 DispatchされるActionの順番 2 ロジック 1 対応したActionTypeのみキャッチするか テスト項目は - 非同期処理や後始末など多岐に渡る用途がある ためテストも複雑化しやすい
- 通信処理などを書くいわゆるビジネスロジック層 - Middleware
Middleware Middlewareのテストが失敗することはビジネス ロジックの欠陥であり、致命的なバグを引き起 こすことにつながる やり方によっては簡素化できる - メインの処理を別の関数やラッパークラスに移譲するなど 関数の呼び出しと引数 - Middlewareは
を確認するのみ 重要度は高いが、低くすることもできる
Container Redux(Action,Store)とReactをつなぐ層 - Reduxに接続してるComponentのテストは Containerのテストも兼ねると言える - 値を渡してるだけなのでそもそもテストする必要 がないという意見も散見される - テストする必要はない(あっても低い)と思われる
Component 3 Stateが正しく更新されているか 2 Propsが渡されているか 1 Componentがレンダリングされてるか テスト項目はPropsとStateを軸に - ユーザが実際に目にするUIが集まるViewの層
- UIの状態や副作用を持つことがある - などが多いと思われる
Component スナップショットテスト E2E 実DOMをテストしたい => 、 ユニットテスト Componentの振舞い(仮想DOM)をテストしたい => Props,
Stateベースの Viewのテストで何を担保したいかで テストの仕方から項目は変わってくる 重要性は人によってチームによって変わる
React Componentは与えられたPropsを元に描画 して仮想DOMを生成するだけ 仮想DOM⇔実DOMのテストは React Fibre側が担うべきテストだとも言える ユニットテストで行うにはオーバーテスティング React Component React
Fiber React Vertial DOM DOM
まとめ 何を担保したいのか明確化されていないテストは 技術負債と同じ - 明確化するとテスト項目や文言は定まってくる - React/Reduxの各層の役割をまずは理解しよう - テストはなぜ行うのか明確化することが大切 -
ご静聴ありがとうございました!