テスト駆動JavaScript 読了
会社同期に薦められて読んでいた。 具体例が長く流し読みしたりしたがとりあえず読了した。
プログラマーのためのJavaScriptではホイストなど曖昧だった部分を改めて学ぶ機会になりました。 特にActivationオブジェクト辺りについて勉強になりました。
主題のTDDについてはCommetライブラリを実装する具体例等で学べます。 個人的にはここは長ったらしく感じてしまいました。
読んだり関連情報をwebで調べたりして勉強になった事は
- 言語・ライブラリの勉強にテストコードを書いておく
- 良さそうな組み合わせ
- TDDの効用
- 良い単体テストの方針
- 控えめなJavaScriptの目的と規則
いささか基本的な事が多いけど、 業務で単体テストやリファクタリング、その他の重要性を主張しても 技術側からすら反論されたりすると上手く答えられず不甲斐なく終わっていたので、 改めて知識や論拠を確認するきっかけになりました。
tips: 言語やライブラリの勉強時にテストコードを書く
言語やライブラリの簡単な挙動確認でREPLを使う事がある。 ここでテストコードを作っておくと再確認が楽ですよって話でした。
特にJavaScriptは効果が大きい。 理由は実装系(ブラウザ)が多く増え続けているため。 新しいブラウザや処理系が出るたびに学習テストを走らせれば変化を直ぐに確認できる。
良さそうなJavaScriptテストフレームワークの組み合わせ
最終的には下の2つの組み合わせのどちらかが良さそうと考えた。
本書というか関連してWebで調べた結果だけどJavaScriptの場合テストを実行するにあたり3つレイヤーが協調する必要がある。
| 名前 | 内容 |
|---|---|
| リモートテストランナー | ホスティング環境(ブラウザなど)でテストを実行する |
| テストフレームワーク | テスト結果を管理する |
| アサーションライブラリ | テストを行なう |
リモートテストランナーに付いてはid:teppeisさんの記事 で触れられています。
本書で紹介されているリモートテストランナーはjs-test-driver です。
最近はjs-test-driverは非推奨でもっと良いランナーの選択肢がある様子。 ちなみにリンク先のtestacularは現在Karmaに名前を変えています。
前にYeomanで何かのスケルトン叩いて遊んだ時にKarmaが使われていたので、 特に他の理由が出てこなければKarma から入ろうと思う。
テストフレームワークはJasmineと Mochaがメインストリームっぽい 。
そして何が理由かよくわからないけどMochaの 人気が登っているらしい。 (なんかさっきから根拠が同じ記事に向かっている…しかもその記事の根拠は弱い)
Mochaの場合アサーションライブラリにSinon を使う事が前提になっている。 一方Jasmineはアサーションライブラリも付いてくる。
なので「手を付けてみようかなー」と思っている組み合わせは以下になる。
TDDの効用
- 動くコードが手に入る
- 単一責任の原則を守りやすくなる
- 意識的な開発が強制される
- これは開発者の開発速度向上にも繋がる
- 生産性が向上する
- 回帰テストが多くなり"時間コスト/品質"を小さくし易いという意味
- リファクタリングしやすくコードの品質(簡潔さ)を維持できる
最後のリファクタリングし易くってのはリファクタリング とか レガシーコード改善ガイド とかで書かれていた気がする。 業務で個人的に実践する様になってから強く実感してる。
良い単体テストの方針
- テストには意図がはっきりわかる名前をつける
- 斜め読みしやすい名前
- テストを<セットアップ/実施/確認> に分割する
- テストを単純に保つ
- 重複個所を取り除く
- テストにロジックを含めない
- 1つのテストでは1つの振る舞いをテストする
- 振る舞いをテスト内に閉じ込める
控えめなJavaScriptの目的と規則
目標
- アクセシビリティ 多くのユーザーエージェントが利用出来る形を保つ
- 柔軟性
- 外部ソースに変更を加えなくても文書構造に簡単に変更を加えられる様にする
- 文書に手を加えなくてもJavaScript, CSSに修正を加えられる様にする
- 堅牢生 振る舞いを段階的に追加する事を可能にする
- 機能検出を用いて動作する機能をユーザーに応じて安全に追加する事を可能にする
- パフォーマンス 外部スクリプトをWebページ全体でキャッシュさせる
- 拡張性 新ブラウザで機能拡張を容易に行なえるようにする
ルール
書かれてたルールをまとめると以下になった。 JavaScriptは外部コードと共存する・実行環境が多様って事を強く意識する必要があり、 その辺が強調された内容だった。
- 実際に機能するか確認してから実行するように書く (外部スクリプト・マークアップ・ユーザーを勝手に想定しない)
- モジュール間の結合度を落とす為にイベントを使う
- 問題の責任を何処に持たせるか考えて繰り返しを減らす
- グローバルスコープを出来るだけ汚さない