「和田卓人の“テスト駆動開発”講座」を読んだ
これです。
この連載は、WEB+DB PRESSfでテスト駆動開発の特集をしたときにフィードバックに答えるために企画したそうです。
フィードバックの内容として、「もう少し初心者にもわかりやすく」「もっと突っ込んだ内容をもう少し詳しく」「もう少し実践的に」という内容があったようで、連載の前半は初心者にもわかりやすく連載第2回は「テスト駆動開発」とは何か？というタイトルで連載が始まっています。
さらにテストとはどういうものなのか、テスト駆動に慣れていくのにはどうすれば良いのか、という内容に触れ、後半では和田さんがTDDに目覚めた話なども入っております。
TDD初心者でも最初から読み進めると一歩ずつ理解できるような構成になっていると感じました。
また、連載の各記事の最初に動画があって、ホワイトボードを使って解説してくれているので、わかりやすいと思いました。（記事はその動画を文字に起こしたという感じ
とくに印象に残った
第3回 「テスト」という言葉について ── Developer Testing，Customer Testing，QA Testing
第3回の記事でテストという言葉広義に解釈されるので、まずテスト駆動開発における「テスト」とは何なのか？という説明がされているのですが、ぼくもこの「テスト」という言葉を誤解していて、この回を読んでDeveloper Testという言葉を知ってテストに対する考えがわかりました。
第9回 テスト駆動開発の「サイクル」――次にテストリストでToDoを洗い出し，レッド，グリーンでサイクルを回す
ToDoをテストリストという形にしてやるべきことを明確にする。
開発対象の機能を考えている際には，
こういうことをやらなければならない， ああいうこともやらなければならない， という課題・ ToDoが次々に浮かんできます。それらのToDoを， まず簡単に箇条書きにしていくんですね。箇条書きにするのは紙でもテキストファイルでも結構です。これをテストリストといいます。
さらに、大きい機能をRED-GREEN-リファクタリングのサイクルで回すときはREDの状態が1週間や2週間かかるかも知れない。その状態は好ましくないので、そういう場合は小さい機能にテストリストとして分けてそれをRED-GREEN-リファクタリングのサイクルで回していくんだ。みたいなことが書かれてます。
タスク分割のときの考え方に基づいてるのかなと思いました。大きいタスクは分割しないとね。
ただ、REDの状態が1週間というの極端ですが、実際はREDの状態はどのぐらいを目安にしてるんでしょうねー。というのは気になりました。が第10回はそれが題材でした。笑
第10回 テストの最小単位は不安
ぼくが第9回で感じた疑問「実際はREDの状態はどのぐらいを目安にしてるんでしょうねー。」はREDがどのくらいの時間になるのかで分けるのではなく、不安に感じている最小の部分をテストするということでした。
例えばif文1つでも不安と思うならテストをするってことです。
プログラマとしての私は，
if文の条件部分のミスや， 配列をループしたりするときにカウンタ値を1個間違えてしまう （フェンスポストエラー） といった， すごい単純ミスが多いんですね。
これにはすごい共感して、ぼくも単純ミスが多いのでTDDでカバー出来たらと思います。
あと学習テストの話。
これからコードを書く際に，
自分が使おうと思っている技術， たとえば未経験のライブラリの使い方に対して不安がある場合に， それをテストの形で書いて技術検証することを 「学習テスト」 と呼びます
私は何回やっても忘れてしまうことが多いため，
暗記できないものに関しては， 自分でその場でライブラリの使い方などに対するテストを都度書いていって， その使い方が機能する （テストがグリーンである） ことを自信の根拠にします。
これもすごく共感しました。忘れちゃうんですよね。。。
学習テストという言葉も初めて聞いたのですが、先輩がライブラリの使い方調べてるときに調査用のリポジトリ立ててテスト書いてたのを思いだました。あれが学習テストだったのだと。
これからは意識してやっていこうと思った。
第11回 テストの資産価値
不安をテストにするなら、新人は不安だらけだからすごく小さいテストが多くなる。
そうした場合、リファクタリングとか仕様変更とかでテストが要らなくなるケースがある。
新人はそれに対して「もったいない」と感じる人がいるが、そういう人に対してどう思いますか？という質問からの記事です。
これはぼくも気になっていて、「もったいない」とは思わないんですが、テスト自体消して良いのかな？と思っちゃいます。
今まで必要で書いてきてて、それが要らなくケースとは？そこリファクタリングするときどうするの？って。
その答えは
リファクタリングで小さい粒度のテストが赤くなったときには，
もうそのテストは役目をある程度果たしていると考えています （注1）。 ですから，
テストをその時点で捨ててしまうこともあります。ただし， 小さいテストを捨てるという判断をするときには， 当然それらのテストを包含している大きいテストがあることが前提です。
でした。
なるほど、それらを包含しているテストがあれば確かに要らないか・・・。
ただし、TDDで開発してるんだからその包含しているテストも速くないといけないよね。ってことで良いんですよね？
それらを包含しているE2EのテストをFluentLeniumで作ったから捨てるぜ！ってわけにはいかないですよね？って理解であっているかな。
第20回 テストコードの重複はアリかナシか
ここは連載で意見が割れてたところなんですが、ぼくは重複ナシ派だなーと。
厳密に言えば、なるべく重複なくしたいなーと。仕様が変わった時に重複箇所全部触るのはちょっとなーという感じです。
ただ、テストコードの重複をなくす＝テストコードのリファクタリングをするという話は大きくなるそうで。
なぜ大きいトピックかという説明を，
少しだけしましょう。リファクタリングをするためには， テストが必要ですというのが， リファクタリングの大原則としてあります。ということは 「テストのリファクタリングを行うときには， テストのテストがないといけない」 という話にどうしてもなってしまいます。
確かに！これどうするんだ。。。
『達人プログラマー』ですこし言及されてるみたいなので読んでみようかな。
まとめ
この連載2007年開始なんですね。。。
この業界は技術の進歩が速いので、ぼくは2年、3年前の記事は割と懐疑的に見るんですが、この連載はまったく色褪せていないと感じました。
まずはTDDでコード書いてみようと思います。
