レガシーコードからの脱却
ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

David Scott Bernstein 著
吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳
オライリー・ジャパン 2019年
https://www.oreilly.co.jp/books/9784873118864/

第Ⅱ部　ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
　10章　プラクティス6 まずテストを書く
　11章　プラクティス7 テストでふるまいを明示する
　12章　プラクティス8 設計は最後に行う
を読んだメモ

プラクティス6 まずテストを書く

「テスト駆動は死んだ」

TDD is dead, Long live testing.
https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

テストではなく仕様である

受け入れテスト、QAテストの代用にはならない。
QAテストの観点で「テスト駆動開発」をするとテストが重すぎる。

テスト駆動開発の目的を見失うと失敗する

テスト駆動開発の目的

・「作るものは何か」を明確にしテストしやすいコードを書く。
・頻繁なフィードバックを得る。
・リファクタリングをしやすくする。
→テストはふるまいの仕様であり、回帰テストである。

テストもソースコード

テストも「CLEAN」を保つ。
→テストが開発のブレーキとなるのを防ぐ必要がある。

プラクティス7 テストでふるまいを明示する

テストではなく仕様である(2回目)

テストは実行可能な生きた仕様。
ドキュメントに書かれた仕様が実装と一致していることを確認するのは困難。

カバレッジを100%にする

テストは仕様であり、仕様と実装は対応する。
仕様にないパスは実装すべきではない。
→コードが複雑になるのを防ぐためのテスト駆動開発。

バグはテストの不足

バグを再現させるテストを書いてから修正する。
→バグを修正するだけでなく、プロセスを改善するきっかけにする。

プラクティス8 設計は最後に行う

注意
ここでの「設計」とは、コードとテストができている状態から、保守性を維持するための設計活動。
※すべての設計を最後まで先延ばしにするわけではない。

テストを最初に書いて、最後に設計をしよう。

テスト駆動開発は設計方法論

テストがあることで安全にコードをクリーンアップできる。
開発の中で学んだことを設計に反映する。
→開発中の課題から手がかりが出てくる。

コードは読むためのもの

読みやすいコードは保守しやすい。
「何をやるか」をプログラミングする。「どうやってやるか」はオブジェクトの中にカプセル化する。

つづく