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
630
Riot.jsのタグをユニットテストする
Riot.js におけるユニットテスト技法と Riot-test-utils の紹介です。
karak
August 29, 2018
Tweet
Share
Other Decks in Programming
See All in Programming
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
820
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
1
150
Deep Dive into ~/.claude/projects
hiragram
14
2.5k
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
14
4.8k
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
170
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
320
NPOでのDevinの活用
codeforeveryone
0
840
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Making Projects Easy
brettharned
116
6.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Statistics for Hackers
jakevdp
799
220k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
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)