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
フロントエンドにおける テスト方針〜Testing Trophyの概念とBDD〜
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
やじはむ
October 25, 2023
Technology
8.2k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
フロントエンドにおける テスト方針〜Testing Trophyの概念とBDD〜
2023/10/25 CTOA若手エンジニアコミュニティ 勉強会 #4
やじはむ
October 25, 2023
More Decks by やじはむ
See All by やじはむ
TypeScriptのパフォーマンス改善
yajihum
21
12k
アクセシビリティを考慮したUI/CSSフレームワーク・ライブラリ選定
yajihum
3
2.6k
Other Decks in Technology
See All in Technology
In-Context Learning再入門。ICLの勾配降下的解釈の研究動向を追ってみる。
dai08srhg
1
770
[dbts2026]数十PBの超巨大データ×AI活用を支えるSnowflakeの実力〜大規模環境におけるアーキテクチャと運用のリアル〜
y_matsubara
0
120
Kiro を使うコツ (頼み方、覚えさせ方、任せ方) | 目指せ Kiro マスター 09
inariku
PRO
3
110
基本から分かる!AWSセキュリティ運用の考え方と任せ方
cmusudakeisuke
1
470
Kiro Crew の Bot (続く役目を任せる窓口) | 目指せ Kiro マスター 12
inariku
PRO
2
350
SREのためのFinOps入門
muziyoshiz
2
730
お客様の「やりたい」の先を見通す合意形成プロセス ~裏にある課題と不安を解きほぐすコツ~
yukakoseki
0
130
並列度を下げたら速くなった — go build の重複コンパイルを実測で見る
tomoaki25
2
1k
llm-d に入門してみた / Try out llm-d
kota2and3kan
0
100
「AIチャットからもできないの?」と言われたら ~業務アプリをMCP対応するときの認証・認可の勘所
oidfj
0
260
現場を動かすAIエージェント#2_製造業現場でのAI活用から見た、ハマる罠と実践知
kintotechdev
2
210
HQ駆動開発で最高のAI-Contextを作ろう
sansantech
PRO
1
120
Featured
See All Featured
Paper Plane
katiecoart
PRO
5
55k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
1
300
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
980
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
320
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
1
600
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Ruling the World: When Life Gets Gamed
codingconduct
0
440
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
510
YesSQL, Process and Tooling at Scale
rocio
174
15k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
630
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.7k
The AI Search Optimization Roadmap by Aleyda Solis
aleyda
2
6.4k
Transcript
フロントエンドにおける テスト方針 やじはむ @yajihum 2023/10/25 @CTOA若手エンジニアコミュニティ 勉強会 #4 〜Testing Trophyの概念とBDD〜
@yajihum @yajihum https://yajium.day やじはむ 自己紹介 ↑ロリス @COMPASS Front-end Engineer 社会人2年目
フロントエンドのテスト、 何を意識して書いてますか? 突然ですが... そもそも、ただ書くのではなく、何かを意識しながら書けていますか?
BDD Testing Trophy 弊社では最近、以下を意識してテストを書いている
E2Eテスト End to Endの略 ヘッドレスブラウザ+UIオートメーションで実施するテストのこと Integration(結合)テスト コンポーネント間の相互作用をテストするもの 単体テストより単位が大きく広くカバーする Unit(単体)テスト コンポーネント単体をテストするもの
コーナーケースの検証の向いている 静的解析 TypeScriptやESLintなどによる静的解析 前提として、テストの種類には以下の4つがある
どの範囲のテストにどれくらいのコストをかけるか テストピラミッドの図 参照:https://gihyo.jp/dev/serial/01/savanna-letter/0005 テストピラミッドは、 Unitテストの比率が一番高くな るようにしている フロントエンドのテストにおいて 本当に効果的か?
最適化の答えの一つ Testing Trophyの考え方 Testing Trophyの図 参照:https://testingjavascript.com/ Testing Library の 作
者 で あ る Kent C.Doddsは、 Integrationテスト に最もコストをかけるべきだと 言っている
なぜInteg rationテストか? Testing Trophyの図 参照:https://testingjavascript.com/ コンポーネントだけで成立する機能は ほとんどない フロントエンドにおいて、単体の Integrationテストが一番 効果とコストのバランスが取れている
ソフトウェアが正しく動くことを 保証する効果が薄いのに単体テストを多 く書くことは最適ではない
Testing Trophyのテスト方針とBDD Integrationテストを多く書くことが大切なのはわかったが、 具体的に何をどう書いていけばいいか? ⭐️実装の詳細をテストしないことが大切
Testing Trophyのテスト方針とBDD 実装の詳細とは? →簡単に言うと、「ユーザーから見えないもの」のこと 例えば、以下の2つの対比がある ユーザーから見えないもの コンポーネント内で使用している関数 ステートなど ユーザーから見えるもの ボタンや表示されているテキスト
UI部分全般
Testing Torphyのテスト方針とBDD なぜ実装の詳細を書いてはいけないのか? False Negative 壊れるべきでないときに壊れてしまう ユーザーの振る舞いを変えずに実装の詳細だけを変更(リファクタリン グ)するときに、実装の詳細を書いたテストは当然壊れる False Positive
壊れるべきときに壊れない 実装の詳細のテストは粒度が小さいため、コンポーネント間の連携などの 挙動を担保できない テストは通っているのに、アプリ全体の挙動は壊れているなどに繋がる
Testing Torphyのテスト方針とBDD ユーザーから見えるものをテストする つまりBDDをするということ! BDD:Behavior-Driven Development(振る舞い駆動開発) 「ユーザーがこれをするとこうなる」という粒度(抽象度)でテストを書くこと になるので、ユースケース単位のコンポーネント間の連携テストが書きやすい
まとめ Testing Trophyの概念とは、各テストの効果とコストを 考えた上で、一番効果的なIntegrationテストをたくさん 書こうというもの Testing Trophyの概念に沿ったテストの書き方として、 「実装の詳細を書かない」ことが大切 「実装の詳細を書かない」→「ユーザーから見えるものを テストする」にはBDDをしよう!
ご清聴 ありがとうございました!
参考 【フロントエンド】コンポーネント指向 React / Vue のテスト 方針 テストピラミッド~自動テストの信頼性を中長期的に保つ最適 なバランス~ フロントエンド開発のためのテスト入門
今からでも知っておき たい自動テスト戦略の必須知識