TDD Boot Camp Tokyo参加レポート #TDDBC
TDD Boot Camp Tokyoに参加して来ました!
当日の流れは、
午前中に2時間ほど講演、午後に実際に手を動かしてTDDをやってみるというものでした。
メインはもちろん午後の、TDD実体験なのですが、午前中の@t_wadaさんによる講演パートでも、気付かされることがいくつかありましたので、まずはそれを書き留めておきたいと思います。
TDDは、動かすー>きれいにする
コーディングのゴールは、「きれい」で「動く」プログラムを作ること。
そのためのアプローチとして、「先にキレイな設計をきちんとしてから動くものを作る」アプローチと、「とりあえず動かしてからキレイにする」アプローチの二通りがあります。
TDDはこのうち、先に動かす方のアプローチ。
ですが、最終的なゴールは「動作する、きれいなコード」なので、動けばいいというわけではなく、キレイにすることが大切になります。
ですので、、、
Red->Green->Refactorで一番大事なのはRefactor
テストを書いて、そしてそれが動くようになったら、すぐ次の機能に進みたくなるものですが、動作する「きれいな」コードを作るのが目的ですので、最も時間をかけるべきはRefactorです。
テストを書くのに3分、実装するのに3分であれば、リファクタリングに10分かける というように、リファクタリングに時間をかけることが大切だそう。
無事テストがGreen!になったら、すぐ次に行くのではなく、プロダクションコードやテストコードを眺めて、違和感のあるところをどんどんきれいにしていく時間をとるのが大切とのことです。
黄金の回転!
TDDは、Red->Green->Refactor そしてまたRedにもどる、「黄金の回転」が重要であり、特にその中に、Refactorが含まれていることは非常に大事です。
さらに、その回転を、小さく速くまわすことが大切とのこと。
たとえば、3分・3分・10分のリズムで。
さらに、それを1分・1分・3分のリズムへ、というように、小さく速い黄金の回転が重要とのことです。
さらに、なるほどと思ったのが
不安をテストにする
TDDにおけるテストの目的は、不安の解消が目的になります。
例えば、今から使うライブラリに不安がある、など。
逆に言うと、getter/setterのようにバグっていないことがほぼ明らかなものは、TDDの文脈においてはテストする必要がないとのことでした。
※とはいえ、メンテナンス性を考えるとカバレッジの高いテストは残しておきたいわけで(さすがにgetter/setterは要らないですが)、TDDのために書くテストと、保守性を上げるために残すテストコードの立ち位置は少し違うのかもしれないと思いました。
*1:※より