TDDはあんまり使わなくなったけど心の中にある

今日は娘たちとコログ探しして楽しかった。

f:id:bufferings:20170910220749j:plain

この数年間、頭の中にTDDを入れた状態で開発をしてきたんだけど。タイトルに書いた風に思う。

良い所がいっぱいある

見失わずに済む

僕にとってTDDの良さは、まず、自分が何をしようとしているかを見失わずに済むところ。一歩先にゴールを立てて、そこに向かって一歩進む、たどり着いたら、次の一歩を進める。その繰り返し。だから、遠く離れたゴールに対して、急いで走って、途中で道に迷ってどこに向かってるか分かんなくなったりしないで済む。

余計なものを作らなくて済む

「必要なものはこれだよね?」という確認から入って、それを実現するための実装に集中するから余計なものを作らなくて済む。実装を先に作ると「こういう機能もあるといいかもだから入れとこうかな」ってついつい入れてしまう。

リファクタリングできる

まず最初に動くものを作ってから、その状態をキープしたまま、実装の改善をすることができる。

最初のクライアントになれる

テストを先に書くことで、その実装がどのように使われるかを、クライアント目線で考えることができる。

「考えたとおりに動いている」と言える

テストを通っているので開発者が「自分が考えたとおりに動いている」と自信を持って言える。「開発『は』終わりました!」って言わなくて済む。

とかとか。

でもあんまり使わなくなった

こんなに良いところがいっぱいあるのに、どうしてあんまり使わなくなったんだっけ?

もう少し大きな単位で考えるようになった

TDDで進めるときは、クラス単位とかメソッド単位で考えてしまうんだけど、複数のクラスを組み合わせた、もう少し大きめの「機能」の単位で最近は考えるようになったかなぁと思う。その単位でもテストを先に考えたりはするけど、それはRed->Green->Refactoringのリズムというよりは、最終的にこれが全部通ってたら大丈夫だね。というようなものなので、ちょっとTDDとは違うかなと思う。

実装をがらっと変えたりする

チームのスキルに合わせて、まずは手続き型でもいいから機能が動く状態に持って行く。その後、その機能が動く状態をキープしながら、中の実装をオブジェクト指向に変えていく。というようなことをちょくちょくやっている。そういうときには、クラスレベルのユニットテストはかえって邪魔になってしまうので、そういうのは手でやったら良くて。どうせ後で使わないし。リファクタリングするときには機能レベルのテストがあれば良いなーと。

あぁ、そうか。僕は最近は機能レベルのテストを使って、ちょっと大きめのサイクルを回すようになったのかもな。

心の中にある?

あんまり使わなくなったとはいっても、TDDの良さについては常に心の中にある。というのは、例えばちょっと要らないものを自分が作ろうとしていることに気づいた時には「それってどういうケースで必要になるんだっけ?」ってテストを頭の中で考えてみて「うむ。要らん。」って言ってみたり、何かに悩み始めたときには「まず一歩進めようかな」って言ってタスクを小さく切り分けて一歩ずつ進めようとしてみたりしてる。のだ。TDDのエッセンスが心の中にあって。そのループは頭の中で回しながら、手を動かすときは、もう少し大きな範囲でループを回してる。という感じ。

だから、TDDはあんまり使わなくなったけど、自分の心の中に染みこんでるなぁ、って思うのでした。

おまけ

僕には「こういうときにはTDDを使う」ってのがある。それは、メンバーに考え方を伝えるとき。「全部を相手にせずに、まずはこのテストを通そう。OKだね、じゃ次にいこう。こういう場合はどうなるのが正しい挙動かな?」とかで、自分の考える順番を伝えたい人がいるときは、TDD使う。「あぁ。今は綺麗にしなくていいよ。まずは動くコードを作ろう。」って。

今日はもう寝ようかな。おやすみなさい。