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
Riot.jsのタグをユニットテストする
Search
karak
August 29, 2018
Programming
1
640
Riot.jsのタグをユニットテストする
Riot.js におけるユニットテスト技法と Riot-test-utils の紹介です。
karak
August 29, 2018
Tweet
Share
Other Decks in Programming
See All in Programming
Automatic Grammar Agreementと Markdown Extended Attributes について
kishikawakatsumi
0
200
2026年 エンジニアリング自己学習法
yumechi
0
140
Smart Handoff/Pickup ガイド - Claude Code セッション管理
yukiigarashi
0
140
組織で育むオブザーバビリティ
ryota_hnk
0
180
OSSとなったswift-buildで Xcodeのビルドを差し替えられるため 自分でXcodeを直せる時代になっている ダイアモンド問題編
yimajo
3
620
AI & Enginnering
codelynx
0
120
16年目のピクシブ百科事典を支える最新の技術基盤 / The Modern Tech Stack Powering Pixiv Encyclopedia in its 16th Year
ahuglajbclajep
5
1k
humanlayerのブログから学ぶ、良いCLAUDE.mdの書き方
tsukamoto1783
0
200
CSC307 Lecture 05
javiergs
PRO
0
500
Grafana:建立系統全知視角的捷徑
blueswen
0
330
AIで開発はどれくらい加速したのか?AIエージェントによるコード生成を、現場の評価と研究開発の評価の両面からdeep diveしてみる
daisuketakeda
1
2.5k
dchart: charts from deck markup
ajstarks
3
1k
Featured
See All Featured
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
117
110k
Mobile First: as difficult as doing things right
swwweet
225
10k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Testing 201, or: Great Expectations
jmmastey
46
8.1k
Become a Pro
speakerdeck
PRO
31
5.8k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
200
Designing Powerful Visuals for Engaging Learning
tmiket
0
240
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
54
Accessibility Awareness
sabderemane
0
56
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
460
It's Worth the Effort
3n
188
29k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
3.9k
Transcript
Riot.js のタグを ユニットテストする Yasushi Kato <https://github.com/karak>
Who are you? Riot-test-utils を作った人 経緯 直前まで React Riot を実戦投入
→テスト書くのつらい
フロントエンドのテストがつらい Riot のいいところ • コンポーネント指向 • 素のHTMLっぽく書ける Riot の悪いところ •
素のHTMLと同じくらい テストしにくい ◦ グローバル状態 ◦ 副作用(含API) ◦ DOMの複雑化
技法 1. Functional なタグ設計 2. Shallow Rendering 3. Snapshot Testing
1. Functional なタグ設計
Functional なタグ設計の4箇条 1. Opts-in 2. Event-out 3. No internal states
4. No external dependency *オリジナルですが、 Redux や未訳の Riot 本も参考。 Opts だけで HTML が決まり、UI は即イベントに投げる 見た目(Presentation)に専念
例:トグルボタン <toggle-button> <a class={pushed: opts.pushed} onclick={handleClick}> ... </a> <style> ...
</style> handleClick() { this.trigger(“push”) } </toggle-button>
2. Shallow Rendering
親タグと子タグの依存関係を断つ search-box の内部に div を1個増やすだけで、 nav-bar(あるいはより上の page)も影響を受けてしまう。 →テストが壊れやすい。unit test ではない。
nav-bar search-box submit-button
一階層のレンダリング <nav-bar> <div class=”row”> <div class=”col-3”> <search-box> <div class=”search-box”> <input
type=”search”> </div> </search-box> </div> <div class=”col-1”> <submit-button> <span class=”submit-button”>....</span> </submit-button> </div> </div> </nav-bar> <nav-bar> <div class=”row”> <div class=”col-3”> <search-box> </search-box> </div> <div class=”col-1”> <submit-button> </submit-button> </div> </div> </nav-bar>
3. Snapshot Testing
DOM構造の変化を検知 <nav-bar /> <nav-bar /> 1回目 2回目 結果を保存 差分検出 <
/> HTML
タグのユニットテストのストラテジー 1. Functional なタグの組み合わせでアプリを作る 2. Shallow Rendering してテストする 3. 見た目は
Snapshot で、 4. UI はイベントハンドラでテストする Riot-test-utils 使ってみて下さい。 (https://www.npmjs.com/package/riot-test-utils)