JavaScriptユニットテストの理想と現実

Slide 1

Slide 1 text

JavaScriptユニットテスト⼊入⾨門 @sota1235 関⻄西Node学園梅梅⽥田キャンパス1時限⽬目 2018/4/20

Slide 2

Slide 2 text

先週の⽇日曜⽇日 • 温泉⼊入りながら資料料作ってた • 考えれば考える程「ユニットテストの書き⽅方はプロに任せたほうがいいのでは…？サバンナの⼈人とか」と思い始めた • もっとフロントエンドの⼈人が苦しんでそうなことは無いかと考えた

Slide 3

Slide 3 text

JavaScriptユニットテスト理理想と現実 @sota1235 関⻄西Node学園梅梅⽥田キャンパス1時限⽬目 2018/4/20

Slide 4

Slide 4 text

console.log(me) • Sota Sugiura(きりん) • @sota1235 • Mercari, Inc. • 将来の夢はJavaScriptになることです

Slide 5

Slide 5 text

東京から来ました

Slide 6

Slide 6 text

今⽇日の話 • テストについて

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

今⽇日の話 • (いろんな恩恵を受けるために)テスト(を書きたいんだけど現実問題、古いコードベースとか設計も何もないコードがあってソースがバンドルされてるわけでもない時、私達はどうするべきなのか)について • 現実のつらみからテストを書ける状態に持っていく話をします • テストの書き⽅方はほとんど話しません

Slide 9

Slide 9 text

アジェンダ • 第1章テストの必要性 • 第2章現実との戦い • 第3章モジュールを切り出す

Slide 10

Slide 10 text

第1章テストの必要性

Slide 11

Slide 11 text

なぜテストは必要か • バグ防⽌止？ • 負荷確認？ • イレギュラー対策？

Slide 12

Slide 12 text

なぜテストは必要か • バグ防⽌止？ • 負荷確認？ • イレギュラー対策？ • →品質担保のため

Slide 13

Slide 13 text

品質とは • 意図した通りに動作するか • きれいなコードか • 想定していない⼊入⼒力力に耐性があるか

Slide 14

Slide 14 text

ユニットテストとは • あるモジュールがある単⼀一の責務を果たしているかをテストする • 最⼩小粒度でのテストを⾏行行う • モジュール単位での品質を担保する

Slide 15

Slide 15 text

例例えば ͤ΍Ͷ • たこ焼きが美味しいと思った時にクリックする”せやね”ボタン • ボタンを押すとカウントアップして押下済みになる

Slide 16

Slide 16 text

ͤ΍Ͷ 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 17

Slide 17 text

ͤ΍Ͷ 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新するそれぞれをテストする

Slide 18

Slide 18 text

責務ごとにテストを分けると • 1テストケースがシンプルになる • モジュールが責務ごとに分かれるよう強制される

Slide 19

Slide 19 text

責務ごとにテストを分けると • 1テストケースがシンプルになる • モジュールが責務ごとに分かれるよう強制される

Slide 20

Slide 20 text

なぜか

Slide 21

Slide 21 text

汚いコードはテストが書きづらい

Slide 22

Slide 22 text

汚いコードはテストが書きづらい＝テストを書けるようにすると綺麗になりやすい

Slide 23

Slide 23 text

せやねボタン document.getElementById('.seyane-button').addEventListener('click', () => { fetch('https://test.com/seyane', { method: 'POST', }) .then(res => { if (res.ok) { document.getElementById('.seyane-button').style.color = 'gray'; } return res.json() }) .then({ count } => { document.getElementById('.seyane-counter').innerHTML = count; }); });

Slide 24

Slide 24 text

Slide 25

Slide 25 text

テスト書きづらい…(´・ω・｀)

Slide 26

Slide 26 text

なぜ書きづらいか • このファイルをrequireしたら即実⾏行行される • イベントリスナに渡される1つのfunctionがいろんなことしてる • 分岐の数の掛け算だけテストケースが増える • 不不確定要素が多い • APIとの通信、DOM APIのコール

Slide 27

Slide 27 text

これが現実だ！！！！ • ⼊入社して全てのフロントエンドのコードがキレイって早々ないと思ってる • たぶん

Slide 28

Slide 28 text

第2章現実との戦い

Slide 29

Slide 29 text

ターゲット • テストが書くのが難しく、またテスト⽂文化もそこまで浸透していない(主観)フロントエンドに着⽬目します

Slide 30

Slide 30 text

なぜテストが浸透していないか • フロントエンドのコードをモジュールでばらして書けるようになったのがここ数年年 • フロントエンドの要件⾃自体が複雑化した • 複雑化したロジックを保守する必要性が増した考察

Slide 31

Slide 31 text

フロントエンド is カオス • ステートフルな世界 • UIとロジックの2つの世界 • 様々な外部要因 • APIとの通信、ローカルストレージ

Slide 32

Slide 32 text

現実 is カオス • N年年物のレガシーコード • Webpack？なにそれ美味しいの？ • リポジトリに威⾵風堂々と居座るjQuery1.x.0

Slide 33

Slide 33 text

どう⽴立ち向かうのか • 既存のロジックにユニットテストを書く • 前にコストパフォーマンスを考える

Slide 34

Slide 34 text

テストは書いて終わりではない • 運⽤用、保守する必要がある • ロジックが変わればテストも書き換える • 品質を担保するためのものに品質を上げる時間を取られてはいけない

Slide 35

Slide 35 text

コスパを考える • テスト対象のモジュールは変更更される可能性が⾼高くないか • テスト対象はロジックでなくUIにまつわるものでないか

Slide 36

Slide 36 text

例例えば • クリックされたら消費税を計算するロジック

Slide 37

Slide 37 text

例例えば • クリックされたら消費税を計算するロジック • 計算ロジックだけならテストしてよさそう

Slide 38

Slide 38 text

例例えば • クリックされたら消費税を計算するロジック • 計算ロジックだけならテストしてよさそう • jQueryで動的に⽣生成されるDOMのclass名

Slide 39

Slide 39 text

例例えば • クリックされたら消費税を計算するロジック • 計算ロジックだけならテストしてよさそう • jQueryで動的に⽣生成されるDOMのclass名 • いろんな都合でclass名変わる可能性が⾼高いしそもそもDOM構造も変わりやすい

Slide 40

Slide 40 text

テストを書く場所の勘所 • UIのテストは無駄になることが多い • E2Eテストが難しいと⾔言われる所以 • コアのロジックは変わることが少ない • 使い回せる粒度に保てば再利利⽤用性も上がる • 「社内npmライブラリとして使い回せるか」

Slide 41

Slide 41 text

第3章モジュールを切り出す

Slide 42

Slide 42 text

モジュールを切り出す • 現実はだいたい多くの責務を持った「何か」がそこにいる • この章ではその何かを実際にばらしあとはユニットテストを書くだけ、という状態にもっていく

Slide 43

Slide 43 text

せやねボタンreturns ͤ΍Ͷ • たこ焼きが美味しいと思った時にクリックするせやねボタン • ボタンを押すとカウントアップして押下済みになる

Slide 44

Slide 44 text

Slide 45

Slide 45 text

ͤ΍Ͷ 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 46

Slide 46 text

ユーザインタラクションとロジックを分離する

Slide 47

Slide 47 text

1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する Ǽ✣ǌ ƺȉǕǿǅǍǽȉ ȃǎǙǅ

Slide 48

Slide 48 text

分離する function onSeyanaButtonClick() { fetch('https://test.com/seyane', { method: 'POST', }) .then(res => { if (res.ok) { document.getElementById('.seyane-button').style.color = 'gray'; } return res.json() }) .then({ count } => { document.getElementById('.seyane-counter').innerHTML = count; }); } document.getElementById('.seyane-button').addEventListener('click', onSeyanaButtonClick);

Slide 49

Slide 49 text

Slide 50

Slide 50 text

ロジックを分離する

Slide 51

Slide 51 text

1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する Ǽ✣ǌ ƺȉǕǿǅǍǽȉ ȃǎǙǅ

Slide 52

Slide 52 text

ロジックの分離 function onSeyanaButtonClick() { fetch('https://test.com/seyane', { method: 'POST', }) .then(res => { if (res.ok) { document.getElementById('.seyane- button').style.color = 'gray'; } return res.json() }) .then({ count } => { document .getElementById(‘.seyane-counter') .innerHTML = count; }); } 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 53

Slide 53 text

Slide 54

Slide 54 text

ロジックの分離 /** * @param {Response} */ function changeSeyaneButtonStatus(res) { if (res.ok) { document .getElementById(‘.seyane-button') .style.color = 'gray'; } } 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 55

Slide 55 text

Slide 56

Slide 56 text

ロジックの分離 /** * @param {Number} */ function updateSeyaneButtonCount(count) { document .getElementById('.seyane-counter') .innerHTML = count; } 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 57

Slide 57 text

ロジックの分離 function onSeyanaButtonClick() { fetch('https://test.com/seyane', { method: 'POST', }) .then(res => { changeSeyaneButtonStatus(res); return res.json() }) .then({ count } => { updateSeyaneButtonCount(count); }); } 1. Clickされる 2. APIと通信する 3. 通信が返ったらボタンを押下済みCSSにする 4. 数字をAPIレスポンスを元に更更新する

Slide 58

Slide 58 text

テスト書けそう

Slide 59

Slide 59 text

現実は泥泥臭臭い • 1つのイベントリスナに詰まっていたものをまずイベントリスナとそれ以外で分けた • その後、ロジックから2つのロジックを切り出した • 後はファイルを分けてテストを書くだけ！

Slide 60

Slide 60 text

つらい現実に⽴立ち向かうには • 今あるコードを紐解いていく • 紐解く時の鍵はUIとロジックの境⽬目 • 紐解いてfunction化、module化したものにテストを追加していく • 簡単なところから少しずつ、ばらしていく

Slide 61

Slide 61 text

余談: テストを書くという⽂文化 • もし今いるチームにテストを書く⽂文化が無いなら積極的にこのアプローチを試してほしい • 1つ簡単なサンプルがあるとみんな真似できる • 新しく追加するロジックでテストを書けるようになる

Slide 62

Slide 62 text

まとめ

Slide 63

Slide 63 text

まとめ • 現実はつらい • つらくてもテストには価値がある • テストを書くための審美眼を極める • UI, ロジックの境⽬目 • コスパの良さ

Slide 64

Slide 64 text

おまけ • 過去に社内向けにmochaのトレーニングリポジトリを作りました • 基礎的なテストを書けるようになりたい⽅方はどうぞ • TwitterなりIssueなりで質問待ってます

Slide 65

Slide 65 text

おまけ • この現実のつらさを越えた先にあるつらさについて過去に発表したのでよければどうぞ https://speakerdeck.com/sota1235/importwomotukusuruhua

Slide 66

Slide 66 text

ご清聴ありがとうございました