「テスト駆動開発とは何であって…」の感想とコミット粒度のアイデア
テスト駆動開発とは何で合って、何でなかったのか？
「fukabori.fm - 114.テスト駆動開発とは何で合って、何でなかったのか？」 - iwashiさんのPodcastを拝聴した感想です。自分が特に印象に残った部分をピックアップしますが、文脈ありきで聴いた方がブレがないので、フルで聴くのをおすすめします。また、サイトに t-wadaさんのブログリンクもあるのでそちらもご参照ください。
併せて、TDDを実践するにあたり、こんなコミット粒度もありなんじゃないか？というアイデアが湧いたので、そちらも書いてみます📝
品質保証のやり方ではなく、プログラミング手法(00:06:15~)
プログラミングの書き方。設計と実装のやり方
ここの話でTDDに対するハードルがグッと下がりました。プログラミングのHOWについてなので、「TDDだとうまくプログラミングできるかも！」という話で、「開発者全員に押し付けるものではないんだな」という感想を持ちました。開発者によっては、「後でテストをまとめて書くスタイルが効率いい」という人もいるかもしれません。それが事実なら強制しなくてもいいと感じたので、 「自分はTDDでやってみる」 という小さなスコープから始められる気がしました。
先にテストをたくさん書くことが、テスト駆動開発ではない（00:17:27~）
「テストファースト」という手法ではあるんですけど、「テスト駆動開発」ではないんですよね
まさに自分も抵抗を感じていたポイントでした。ウォーターフォール的に「テスト → 実装」あるいは「実装 → テスト」を行うのではなく、半径の小さいサイクルで回して 実装フィードバックによる設計の見直し と 設計フィードバックによる仕様漏れ検知あるいはリファクタ を実践し、いい塩梅を見つけていく手法なんだと知りました。また、
- テスト・インターフェースの設計一辺倒だと若干、理想寄りでオーバーエンジニアリングになりがち
- 実装一辺倒だと、現実寄りでアンダーエンジニアリングになりがち
とおっしゃってるように、両者のちょうどいいを探せることが、テスト駆動開発がスムーズにエンジニアリングできる根拠なんだと思いました。自分は今までは「テスト駆動開発はオーバーエンジニアリング」と勘違いしていて、このメリットについても、エンジニア以外にも理解してもらえそうです。
テストコードは「使う側の視点」なので、使いやすさに目を向けやすくなる(00:32:25~)
「作りやすさ」と、「使いやすさ」って、意外と両立しにくい
テストファーストの利点について、芯から理解できたコメントでした。「ぼくがかんがえたさいきょうの関数」みたいなのが、チームになかなか使ってもらえない＆認知してくれなかったり、逆に「0から書いた方がわかりやすい……」みたいな関数があったり、そういった事象はチーム開発においてよくあるかなと思っています。これは「コードの統一感」や「レビューコストの増大」につながると自分は考えていて、そのために、使いやすさの観点は非常に大事だと感じていました。テスト駆動開発によってここをセルフレビューまたは過剰な関数の生産を防げるのはとてもいいことだと思いました。
テストリストとは「備忘録のようなもの」（00:41:32~）
「網羅する」っていうより、もっと軽く考えたほうがいいので、「備忘録のようなもの」なんですよね
テストリストについて、どう取り扱ったらいいのか疑問に思っていたのでクリアになりました。「やっぱり先にテストケースをテストコードに残しておかないといけないのか？」って疑問はまさに湧いてました。そうではなく、たとえばメモのように残しておき、そこから１つずつピックアップしてテスト駆動開発を進め、途中で新たな仕様・要件に気づいたら気軽にメモに追加しようと思いました。
テスト駆動開発とは、プログラミングの楽しいところが長続きするやり方(00:44:45~)
一番大事でみんなにも広めたいと思いました🙆♂️
コミット粒度のアイデア
以上の知見と、t-wadaさんのツイートを元に、自分なりにコミット粒度の指針を考えてみました🙋♂️
コードには How
テストコードには What
コミットログには Why
コードコメントには Why notを書こうという話をした
実装とテストをセットでコミットする
whatとhowが1つのコミットに凝集され、コミットログにwhyが記されています。振り返りやすくなるので、なるべく関係するテストコードもセットにした方が、コードで雄弁に語れるのではないかと思いました。
「レッド・グリーン・リファクタ」もしくは「グリーン・リファクタ」の粒度でコミットする
より細かい単位でコミットする場合は、テストがレッドの場合もコミットを切り、プロダクトに必要なコミットだけ残したい場合はテストがグリーンの場合とリファクタの単位でコミットを切るアイデアもいいかもと思いました。その段階で何ができて何ができないのか、追いやすくなりそうです。
テストリストをメモとして、WIPコミットに残しておき、最後に消す
途中段階のコミットに.mdなどでテストリストを書いておき、コミットと共にテストリストも更新します。やらなかったテストに関しては、コードコメントに「why not」として残し、最終的にはファイルを削除し、完成コミットとする方針も、読みやすそうだなと思いました。
まとめ
個人的に、人にとって読みやすいコードにしたいと思っています。そのためにテスト駆動開発は有効だし、新しいコードを見るときも、テストコードから仕様を追うと理解しやすいという実感もあったので、可読性が上がるなと思いました。特に「テスト駆動開発とは、プログラミングの楽しいところが長続きするやり方」という言葉は印象的でした。「テスト駆動開発はトモダチ。コワクナイヨ」って標語を思いついたので、周りにも布教したいと思いました😇
Discussion