ToDoリストのすすめ

TDDBCでTAやってぼやっと思ったことシリーズ。シリーズ？続くの？

- - -

TDDBCのお題はざっくり「何ができるか」が書かれてることが多いですが、これはテストを書くのに十分な粒度ではありません。少なくともお題をそのままテストメソッド名にしてしまうのはダメなパターンです。簡単なところは上手く行くこともありますが、すぐに厳しくなると思います。
これは実際の開発でもよくあります。例え設計者が別に居たとしても、詳細設計書に書かれているものが十分であったことはあまり記憶にありません。咀嚼して適切な粒度に整理し直す必要があります。*1

TDDでのテストの歩幅は人それぞれだなので、明確な答えを示すことはできませんが、「何をテストすればこれができたと言えるか」が明確でない……言うなれば assert から書き始められない場合は、階段の段差の高さが自分のスキルに見合っていないと言うことです。

まず全体を見て、どこから手をつけていけば良いかを整理して、必要ならばバラして。分からないものはそのままに……するんですが「どれができればそこに手をつけられそうか」をぼんやりでも考える。そうしてテストしたい内容を ToDoリストに書き出していきます。

とは言え適切な粒度に最初からバラせるはずもありません。順番も入れ替わるかもしれません。なので、ToDoリストはこんな感じであって欲しいです。

一覧性が高い。
容易に追加出来る。
容易に削除出来る。
容易に順番が入れ替えられる。
階層を分かりやすく表現出来る。
依存関係やグループをわかりやすく表現できる。

これに向いているのはソフトウェアのマインドマップです。単なるテキストでは依存関係を上手く表現出来なくて悩みました。手書きでも良いのですが、削除や順番入れ替えに弱いことと、階層を重ねるとすぐに紙の端になって困ります。*2

補助階段を作る

誤って大きな段差にチャレンジしてしまった時に、通らないテストを前に長時間プロダクトコードをあーだこーだと弄っているのもちらほら見ました。
私のイメージでは、Redは息を止めている状態です。Greenの時のみ呼吸ができます。10分も息を止めるとか人間業じゃありません。

こういう時は落ち着いて一歩下がるべきです。テストが大きすぎたことを受け入れる。Redが続いてるのは嫌なので、消すか一旦は ignore にする。コーヒーを飲む。そして、その大きな段をのぼるための、小さな段を用意する。

大きな段をのぼるためには、しっかりした踏み台を用意するのがいいです。大きな段へのチャレンジは、滑り落ちると危険が危ないですし、のぼれたとしても凄く体力が要ります。階段を積み上げておけば、踏み外しても大丈夫かもしれません。たまに滑り落ちますけど、たまにです。

誘惑を押し付ける

ToDoリストは単に最初に書き並べておくものではありません。サイクルをまわしている時は目の前に集中するべきですが、人間はいろんな誘惑に駆られます。それが悪いわけではありません。例えばそれは、コードの発する異臭（リファクタリングすべき箇所）かもしれません。でも、気づいたからと言ってすぐに手を出してはいけません。RedからGreenへのステップとリファクタリングを同時にするのはまずいです。たいてい大丈夫なんですけど、リファクタリングの多くはIDEがカチカチっとやるものなので、たいてい後回しにしても大丈夫です。気合を入れてやらなければならないリファクタリングは、なおさら同時にするべきではありません。

「リファクタリングしなきゃ今の実装が書きづらいじゃないか！」と思ったならば、おめでとうございます。それは今のRedに入る前のリファクタリング漏れに気づけたと言うことです。一律なパターンを出せるほど意識はしてませんが、自分の書いたコードなら、違う処理であってもなんとなーく似てくるんです。次に「こんなリファクタリングをしたくなったことがあったなー」と過ってくれるようになります。たぶん。３回くらい面倒くさい思いをすれば。

ToDoリストは目の前の問題に対処するためのものです。誘惑に駆られた時、ぐっとこらえてToDoリストに書く。思いついたことは特にすぐに手をつけないと忘れちゃうので、後回しにするための補助記憶装置として書いておく感じです。「やらなきゃー」と思ってToDoリストに書いて、後で見たら「別にやらなくてもよくなったわー」となることもあります。