TDDBC 2ヶ月後のふりかえり - 考え方の変化

6/3 に TDDBC大阪2.0 に行ってから、もうすぐ２ヶ月。
ということで、TDD についてふりかえってみます。

自分なりにふりかえりをしてみて、KPTをまとめる。
そして、今後のTDD実践に役立てたいと思います。

※２ヶ月前のエントリはこちら
TDD Boot Camp 大阪 2.0 に行ってきた - Java開発のんびり日記

考え方の変化１　TDDは開発者のためのテスト

@t_wadaさんが講演でおっしゃっていたことですが、
「開発者が開発促進のためにテストをする」＝TDD
「品質保証担当者が品質保証のためにテストをする」
「顧客が進捗確認のためにテストをする」

TDDは開発促進のためのテストであるという考え方は聞いたときに衝撃を受けたのを覚えています。開発者にとってのテストとは、必ずしも品質保証のためではないという解釈に驚きました。
そして、TDD を実践していくなかで、より一層この考え方の腹落ち感が深まっています。

これまでは「テスト＝つまらない・価値が少ない」という考えでした。わざわざテストしなくても、エビデンスを作らなくても、コーディングしながら動作確認している。テストする暇があったらコーディングして開発進捗をあげるべしと思っていました。

今思ってみると、お恥ずかしい限りですね。

初期開発のことしか考えておらず、保守や回帰テストのことを考えるとそうはならないだろう…というのもあるのですが、それはここでは横においておきます。

ともかく以前の考えでは、テストは開発を阻害する邪魔者だったわけです。本人はもっともっと開発したいし、開発する必要があったので、まあ当然の流れです。そのようななかで、品質保証のためのテストをするという工程は苦痛でしかないのです。仕方なくやる。

開発促進のためのテスト、品質保証のためのテスト。その分類をすることがこの矛盾的な状況をうまく交通整理してくれました。
開発促進のためのテスト（＝TDD）なのであれば、喜んでテストコードを書けますし、仕様変更のしやすさやリファクタリングのしやすさを実感することでさらにテストを書きたくなります。Red→Green のサイクルを繰り返す快感は今となってはなくてはならないものです。

一方で、品質保証のためのテストは開発（コーディング）とは割り切って、別の作業工程として位置づけることで「はやく開発したいのに」という反発心から解放することができました。
（とはいえ、品質保証のためのテストはまだまだつまらないですけど）

考え方の変化２　Red/Green/Refactor

Red/Green/Refactor のサイクルを速くたくさん回す。TDD でもっとも言われることかと思います。
前述しましたが、このサイクルを回す意図と快感は実際にやってみないとわからないです。そして、開発リズムが自然と生まれてきて、フロー状態になると開発スピードの上昇は半端ないですね。

ペアプログラミングと組み合わせると、その効果は倍増すると思います。TDDBC 後はペアプロを実践できていないので、推測レベルですが。

どんな具合にやっていけばいいのか、イメージがつかめないという疑問や不安は『テスト駆動開発入門』を読むことで解消できました。弾みをつけることができました。

考え方の変化３　MVPを意識できるようになった

現在担当している案件では、アジャイルな開発をしています。
MVP（Minimu Viable Product：実用最低限の製品）や「価値を早く継続的に提供する」をアジャイルでは意識しておかなければなりません。そういった考え方に、TDDはうまくマッチしていると思っています。

TDDでは、最短パスを通すイメージで開発を進めるので、無駄なく動くものが始めにできあがります（Red→Green）。
そこからリファクタリングできれいにしていくことになります（Green→Refactor）。

これを何度も繰り返すわけですが、大きな括りであっても（例えば、デモやリリース）、その方法論は継続し繋がっているイメージになります。とりあえず版みたいな感じです。不確かな仕様を実現する場合や不明点がある場合には、すぐに確認がとれます。
実装もせずに、動くものもなく、設計書だけで、あーだーこーだと議論する曖昧さに比べると天地の差ですね。

イテレーション内で実現できるボリュームを超えている場合、もしくはイテレーション途中で計画していたレベルまで到達でない場合には、MVP という考え方は非常に有効です。現時点ではここまででリリースしましょうかという調整ができますし、実装はたくさんしているが結局は動かせないレベルで顧客からすると価値ゼロといった困った状態も回避できます。

TDD で実装したコードは自動的に「テストケースでコードを保護できている」状態になっています。機能追加や仕様変更は基本的にテストケースを追加し、コードを変更する手順になります。その際、以前のテストケースの成否を確認することでデグレや予期しない動作不良を防ぐことができています。
小さく作って、後から拡張していくのがとても簡単にできます。

視点が違いますが、障害対応についても少し。
どこかに書いていたことですが、障害が発生したらその障害を再現するためのテストケースを追加して、それからコードを修正します。この手順はとても効果的です。のちのち、修正内容や修正理由をトレースすることができます。コミットコメントだけでは心もとないですし。