TDDって？

TDDとは何か。テスト駆動開発。開発をテストでぶん回すこと。とか言ってもよくわからないので、持ってる本のいくつかからTDDっぽいところを引用して並べてみる。

テスト駆動開発入門

テスト駆動開発は、プログラミング中の不安を管理する方法である。（…略…）道理にかなった不安、すなわち「これは困難な問題だから最初から最後までは分からない」という感覚である。

テスト駆動開発入門 P.vi

対象は不安。

2つのシンプルな規則に従う事が、潜在能力を引き出す。
・どんなコードを書く前にも、失敗する自動テストを作成する。
・重複を取り除く。

テスト駆動開発入門 P.xii

人並みのスキルを持つソフトウェアエンジニアの潜在能力を引き出す手法。

プログラミングは困難である。プログラミング時に、複数のボールを同時に空中に投げているかのような感覚になる事が多くあった。集中が途切れると、すべてがこぼれ落ちる。テスト駆動開発はこのような感覚を減らすことに役立つ。（…略…）テスト駆動開発で作業すると、1度に1つのボールを空中に投げているかのような感覚が得られるからだろう。そして、そのボールだけに集中して、本当に良い仕事を行うことが出来る。新しい機能を追加する時、よい設計かどうかは気にしない。

テスト駆動開発入門 P.210

やる事が明確になり、今に集中できる。機能追加時は、洗練はあとでやるから今は気にしなくて良い。あとで出来ることをテストがサポートする。

Code Craft ~エクセレントなコードを書くための実践的技法~

コードを書きながらテストして、可能な限り早い機会にコーディングエラーを捕捉してください。（…略…）ソフトウェア開発の最中に（ことによると、その前に）テストに着手する事が非常に大切です。アジャイルプログラマーが広めたテスト駆動型開発アプローチでは、テストが重要な構築テクニックだと主張しています。つまり、テストコードをテスト対象のコードより前に書くと言う事です。
（…略…）
コードが上手く動作する事を証明すれば、安心して先に進めます。この時点でテストを書かないと、バグが潜んでいるかもしれないコードを引きずることになります。そうなると、コードベースの安定性が失われます。

Code Craft P.177

エラーを早期発見するためのもの。早く見つけられると安心できる。信頼できないコードを変更していくのは不安の元。（「証明」って言葉に反応されそうでちょっと怖い。）

Clean Code アジャイルソフトウェア達人の技

テスト駆動開発と言う分野は、われわれの業界に大きな影響を与え、いまや最も基本的な分野の1つとなっています。デイブは正しいです。テストのないコードは洗練されているとはいえません。どれほどエレガントであろうと、どれほど読みやすく理解しやすかろうと、テストがないなら、洗練されているとはいえません。

Clean Code P.35

コードを洗練させるもの。TDDが基本的な分野の1つなのは何処の業界の話でしょう…orz

第一則：失敗する単体テストのコードを書く前に、製品のコードを書いてはならない
第二則：コンパイルが通り、適切に失敗する単体テストができるまでは、次の単体テストを書いてはならない
第三則：現在失敗している単体テストが通るまで、次の製品コードを書いてはならない
これらの三原則を目の前にしたら、きっと30秒ほど固まってしまうことでしょう。テストコードと製品コードはほぼ同時に書くのです。テストコードの方が数秒先行するようにして。

Clean Code P.174 TDD三原則

厳格なTDD三原則。

このアプローチの中心となっている教義の中の1つは、システムを常に動かし続けると言う事です。言葉を変えれば、TDDを用いる以上、システムを壊してしまうような変更は許され無いという事です。変更の際には、常にシステムが以前と同じ動作をする事が義務付けられます。

Clean Code P.279

システムが動かないのは新しいテストを追加した時だけになる。

レガシーコード改善ガイド (Object Oriented SELECTION)

テスト駆動開発は、私が知っている機能追加の手法の中で最も強力です。簡単に説明すると、ある問題を解決するためのメソッドを想像し、それに対して失敗するテストケースを書く方法です。メソッドはまだ存在しませんが、先にテストを書くことで、これから書こうとしているコードが実現すべき内容について、確固たる理解が得られます。

レガシーコード改善ガイド P.98

使い方と実現すべき内容が明確になる。

レガシーコードでは、テスト駆動開発を適用する際に、既存のコードに対するテストを書くことが非常に重要です。テストを整備することで、機能追加のために必要なコードを自由に書くことが出来ますし、残りのコードに組み込んでもコードの状態が悪化する事は無いと確信を持つことができます。

レガシーコード改善ガイド P.104

テストが命綱。危険だらけのレガシーコードの中でも、テストの保護により自由と安心を得られる。

テスト駆動開発で大きな価値のあるのは、一度に1つのことだけに集中できる点である。テスト駆動開発では、コードを書いているかリファクタリングしているかのどちらかであり、両方を一度に行うことは決してない。

レガシーコード改善ガイド P.104 テスト駆動開発とレガシーコード

ひとりずつ仕留める。

テスト駆動開発は、オブジェクト指向言語と手続き型言語のどちらでも使えます。作成したいコードに対してテストを明確にしようとすることで、しばしば設計は良い方向に進んでいきます。テスト駆動開発では、関数を書くことに注力し、それをコンピュータ上で動かしながら、アプリケーションのほかの部分と統合していきます。

レガシーコード改善ガイド P.250

使い方から設計を導き出す。同時に一つの事に集中できる。

プログラマが知るべき97のこと

テスト駆動開発（TDD : Test Driven Development）とは、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。

プログラマが知るべき97のこと P.214 不具合にテストを書いて立ち向かう

対不安用兵器。全文引用したいけど、それじゃ意味がないし…。

達人プログラマー―システム開発の職人から名匠への道

TDDって言葉は出ない*1けど、エッセンス的なものは入ってる。

「少しコーディングして、少しテスト」はSmalltalkの世界の合言葉であり、我々も成果物のコードとテスト・コードを同時に記述する際の（あるいは成果物のコード以前にテスト・コードを記述する際の）マントラとして採用すべきです。

達人プログラマー P.241

少しずつ、ひとつずつ。

意図的にバグを混入することによって、テストでそれが検出できるかどうかを検証するのです。

達人プログラマー P.248 テストのテスト

一発で実装がうまく行った時に信じられなくて、わざわざ失敗するように変更した……って経験はプログラマならあるかと。TDDはこれを先に確認してるだけとも言える。

ほとんどのテストは自動的に行われるべきです。ここで「自動的」と表現しているのは、テストの「結果」も自動的に解釈される、ということを意味している点にご注意ください。

達人プログラマー P.250 いつテストすべきか

テストは自己検証可能でなければならない。

つまり、TDDチートシートを壁紙にすればOK。

*1:2000年だし