なぜ早く気づかなかったんだ・・
TDDを諦めた多くの人たちに言いたい。
君たちのTDDの理解は間違えていると。
かく言う私もTDDについて大きく誤解をしていた。
テストファーストという単語に踊らされ、
テスト書いときゃいいんだろ。と思ってた。（ほんとすいません）
私が大いに勘違いし、重要だと思い込んでいたものを今投げ捨てる時が来たようだ。
この機能は簡単ですよ
お、いい設計が浮かんできたぞ！そんなこたーない。
小さく始めるんだ。そして小さく失敗する。
何事も慎重に進めるのがTDDだ。
私は違う？一気に作れるって？
でもどうだい？その作ったコードはテストがかけるのかい？
だいたい書けない。
書けたところで、一つのテストを準備するのに10行も書かなきゃならない。
メンテナンスが大変だ。
依存があるからしょうがない？
違う、小さく始めれば依存を切り分けて、テストフレンドリーにできたはずだ。
メンテナンスコストが小さいテスト。
これこそがTDDでの恩恵である。
カバレッジ
こいつはクソだ。なんの役にも立たない。
今すぐ投げ捨てろ！TDDにおいてカバレッジは役に立つどころか毒にしかならない
TDDにおいて、テストコードは開発の自信だ。
その自信はどこからくるか、間違いなくカバレッジではない。
作ってきたコードたちが壊れていないかを一瞬で確かめることができる。
それこそが自信だ。
そこにカバレッジは一切必要ない。
カバレッジを気にしなくちゃならない？
それはそのコードがクソな証拠だ！
コードをリファクタリングしろ！
小さく分けて、小さなテストを書くんだ！
ほら、カバレッジはどうなった？
テスト技法
同値分割だとか、境界値分析だとか。小難しい奴らだ。
こいつらもクソだ。今すぐ忘れろ！
TDDにおいてはまったく役に立たない。
自分が書こうとしている処理が正しいかを検証することさえできればそれでいい。
それ以外のテストコードは必要ない。むしろ邪魔だ。
重複が増え、見にくくなり、リファクタリングでテストコードの修正が面倒になる。
全く逆効果だ。
テストファイル1:1の法則
Hoge.javaに対してHogeTest.java。
実際のところどう言うのかは知らないが
テストが1:1で対になっていることをさす。
これがTDDで犯す一番の間違いだ。
これは、最終的には1:1に収束する場合が多いだけだ。
TDDの初期に置いて、設計はミニマムでなければならない。
ファイル名は機能名くらいの粒度でいい。
書こうとしている処理がかなり大きい？
それは、TDDの最初のステップじゃない。
もっと小さなステップに分割だ。
Red Green Refactoring!
この処理とこの処理はすごく似てる。
重複は悪だ。なんとか共通化できないか。
ほら、今こそ構造を作る時だ！
親クラスを定義してみる。似ている箇所を共通化してみる。うまくいった！
TDDに導かれ、クラスが分割され、おぼろげにパターンが見えてくる。
ほら、Factoryが見える！
これこそがTDDの目指すところだ！
まとめ
これまでの小話は
テスト駆動開発 を読んだ感想です。
この本の原著は2002年発売。翻訳本は2003年に発売されています。
15年以上前の本ということに驚きしかありません。
その間私は勘違いを続けてきたわけですが。。
テスト駆動開発は同じ原著を2017年に再翻訳し出版されたものです。
昔の本の翻訳だから。とスルーしてはいけません。（1年間してました。すみません）
TDD知ってるけど実践してないと言うそこの人。というかここまで読み進めている人！
買って読んでみてください。（アソシエイトリンクじゃないよ）
読んだばかりなので、興奮冷めやらず勘違いに勘違いを重ねている部分があるかもしれません。
あしからず。