テスト駆動JavaScriptの第2章をメモ
Node塾 講義その６に行くのでメモった
Node塾で下記の読書会をする。
- 作者: Christian Johansen,長尾高弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2011/11/25
- メディア: 大型本
- 購入: 19人 クリック: 331回
- この商品を含むブログを見る
以下は第2章を抜粋したメモ。これを読んで頂ければわかるがテスト駆動JavaScriptはJavaScriptでTDDをするにはどうすればいいかだけに答えるものではなく、TDD未経験者でもTDDとは何なのか？どうやってTDDを身に付けるのかを記載した本になっている。興味があれば買うといいよ。そしてNode塾に参加すればいいと思いますよ。
第２章 テスト駆動開発プロセス
- テストから仕様へ
- テストは本番コードを書く前に、仕様として書かれる
- 利点
- テストがしやすくなる
- インターフェースがクリーンになる
- デベロッパーが自信を持てるようになる
- 利点
- 開発の上下をひっくり返す
- テスト駆動開発における設計
- プロセス
- Step1.テストを書く
- Step2.テストが不合格になるのを確認する
- 合格するコードを書く前にテストを実行する
- 理由
- コードの現在の状態について、私たちの理論の正しさを確かめること
- テストがどのように不合格になるのかについて明確に想定できていなければならない
- （単体テストにもバグがある）
- 理由
- 合格するコードを書く前にテストを実行する
- Step3.テストを合格させる
- テスト駆動開発プロセスにはあるリズムがあり、作られたソリューションがその時点では完璧でなくても、イテレーションを完結させたというパワーを過小評価すべきではない
- 自明の実装
- テストを合格させるために必要なだけのコードを追加する
- コードを追加させるということはふるまいを追加すること
- 追加されたふるまいは、追加された要件によって表現されなければならない
- 明確な要件を背後に持たないようなコードがあるとすれば、それは水ぶくれに過ぎない
- YAGNI「you ain't gonna need it」
- 足場
- ハードコードでもかまわない
- 何も手がかりがないのに一般的なソリューションを探さなければ先に進めないようにすると、時間を使いすぎてしまう
- 開発ペースを保つために、中間的なソリューションとしてハードコードを認めている
- Step4.重複を取り除くためにリファクタリングする
- シャンプー、リンスの繰り返し
- 1歩の大きさを大きくしたくなるかもしれないが、ひんぱんにフィードバックをもらえる状態に保つために、サイクルは短くした方がよい
- 一歩を大きくしすぎると、追跡しにくいバグや手作業のデバッグなど、このプロセスで避けようとしている多くの問題に直面することになり、このプロセスを採用した意味がなくなる
- テスト駆動開発を円滑に進めるために
- 自動テストを実行すること
- ファイルが保存されるたびにテストが実行されるようにするということ
- テストの実行は環境のほうの仕事
- 自動テストを実行すること
- テスト駆動開発の利点
- まとめ
