TDD ミートアップに参加しました

TDDミートアップ - connpass
TDDミートアップ #TDDMeetUp - Togetterまとめ

TDD 実践してないけど面白そうなので行ってきました！
いろんなトピックがあったなかで自分が提案したトピックが取り上げられてよかったです。
ディスカッションした感想というか考えたことを書きました。

TDD とプログラミングパラダイム

個人的に TDD はオブジェクト指向プログラミングと一緒に語られることが多いと感じています。
『テスト駆動開発入門』や『実践テスト駆動開発』では、サンプルコードが Java なので当たり前っぽいですが、『テスト駆動開発による組み込みプログラミング』などは、サブタイトルが "C 言語とオブジェクト指向で学ぶアジャイルな設計" です。

疑問としては手続き型言語で TDD をする場合でもオブジェクト指向な設計に洗練して行くべきなのか？ということでした。*1
一応断っておきますが、別に手続き型万歳！オブジェクト指向なんて嫌い！とか思っていません。
むしろ OOP 好きですし、『テスト駆動開発による組み込みプログラミング』はとても良い本です。
ただ、現実には C のレガシーコードと戦っているので何かヒントを得たいと思った次第です。

ディスカッションでは TDD のために言語が前提としているパラダイムを変えることに意義は少ないということに落ち着きましたが、ちょっと自分のミスリードもあったかもしれません。
帰りの電車の中で自分なりにつらつら考えてみました。

手続き型言語で TDD のサイクルを行うには、少なくとも小さな機能単位での関数に分割する必要がある
- だめなコードにありがちな、1 つの関数にダラダラと手続きが書かれているとTDD のサイクルに乗せるには大きすぎる
- 上記のようなコードを作りにくいのは TDD のメリット
- 特にオブジェクト指向は関係ない
『レガシーコード改善ガイド』によれば、手続き型言語のテストのしにくさは "接合部" が少なく、依存関係が複雑になりがち
- 要はモックが使いにくいということだと理解
- C での接合部としては、リンカ、プリプロセッサ、関数ポインタ
- 設計で接合部は増えない
- やっぱりオブジェクト指向は関係ない
関数を分割する指針として SOLID原則のようなオブジェクト指向プログラミングの考え方を取り入れるのは有効
- ほとんどは手続き型言語にも読み替え可能*2
- 適切に分割すれば依存関係も減りモックも使いやすくなるかも？
- オブジェクト指向！