【超図解】5分で分かるTDD概論、が5分で説明できなかった話
はじめに
先日、岡山県のITイベントでLTを行いました。
現地の皆さんはとても優しくて、とても楽しかったのですが、5分を想定していたLTの時間が伸びに伸びてしまったので、反省と備忘録を兼ねてスライドに書ききれなかった補足をWEBに残すことにしました。
元ネタ
元ネタの元ネタ
https://www.amazon.co.jp/テスト駆動開発-ＫｅｎｔＢｅｃｋ（和田卓人訳）
はじめに、TDDとは何ぞや？
歴史を振り返ると2000年代初頭にケント・ベックさん（XPの人）が著書で提唱した概念。
実際にコードを書く前にテストを書くテストファーストな開発手法。
t_wada本（敬称略）読みやすいけど長い。
Wikiの説明が現状一番分かりやすいかも。
本質的にはエントロピー制御の話を延々としている（気がする）
まずエントロピーとは？
FEで出てくる情報理論の話。（≒情報量）
エントロピーが増えるとプログラミングが大変。
テストやリファクタ等でエントロピーを収束させる必要がある。
とはいえ実際、多くの場合はテストが書かれていない。現場の努力で何とかしている。
自動テストによるエントロピーの収束
仕様を書いた段階では無限にエントロピーが発散している。
テストコードを書くまで、実装コードが正しいことは論理的に確定しない。
仕様→テスト→実装の流れで作業することによって、それぞれが１対１対１で正確に対応。
現場あるあるの予防に繋がる。（ドキュメントが改定されない。実装が追いつかない等）
とはいえ面倒臭くないか？
正確なテストが書ける段階で正確？なコードが分かっているので実質二度手間。
そもそも現場は忙しい。テストを書ける余裕が無い事がしばしば。
JTCの管理職クラスでt_wada本をちゃんと読んだ人を見た事が無い。
上司がよく分からないまま丸投げ、下っ端もよく分からないから雰囲気でテストを書いている。
顧客の課題解決に必須では無いテストを、実装より優先すると言う矛盾。
もっと柔軟に考えよう。
シーケンシャルでやると、どう考えても非効率。
仕様、テスト、実装、この３つを並行で考えられる体制がベスト。
進捗管理には各種ツールが必須。最低でもGitは欲しい。
面倒臭さの先にある利便性
抽象、テスト、具象の３つが自然と一貫性を持つ。
抽象と具象の整理整頓が自然と出来るようになる。
フィードバックループを回せば自然とプログラムが完成している。
みんなTDDをやろう！！
以上です。ご清聴ありがとうございました。
余談
この記事を書きながらふと思ったのですが、僕ってちゃんとt_wada本（敬称略）読めてたかなと思って、改めてもう一回読み直したら新しい発見があったので、以下にその内容を述べます。
前述の通り、TDDはテストを書く事と言うより、テストを通してソースコード、ひいては開発体験の質を向上させる事を目的としていると言うのが僕の持論です。
「1週間紙の上で設計して、その後でコードをテスト駆動で書いたら、それはTDDだと言えますか？」と聞かれたら、もちろんそれもTDDだと答えるだろう。
ＫｅｎｔＢｅｃｋ. テスト駆動開発 (p. 10). (Function). Kindle Edition.
しかしその具体的な方法論として、ケント・ベックさんは上記引用のように抽象的に考えており、ケースバイケースで考えても良いと言うような見解を著書で示されています。（諸説あり）
またその細かい内容についても、著書ではTDD以前にやるべきことが沢山あるよね？といったスタンスが節々で散見され、非常に参考になるのでQAエンジニア以外も読んだ方がいいかもです。
ただ強いて注意点を述べるとすれば、原著であるTest Driven Development: By Example (Addison-Wesley Signature Series (Beck))は20年以上前に出版された本であり、IT業界では実質古典とされています。著者の偉大な先見性により、その内容の多くは現在でも通用しますが、出版当時の時代的、技術的背景を考慮する必要があると思います。
なのでまあ、結論を述べると、TDDは理論上5分で説明できる可能性がありますが、ちゃんとやろうと思うと50分でも全然時間足りないかもです。
余談の余談
末筆ではありますが、とても素晴らしい会を開いていただいたTech Guildさんには感謝です。
今後更に楽しいイベントを開催されるらしいので、興味がある方は以下のリンクから詳細をご確認ください。
Discussion