読者です 読者をやめる 読者になる 読者になる

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

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

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

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

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

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

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

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

当たり障りのない結論になっちゃいますが、手続き型言語で無理矢理クラスっぽいものを作ったりするのはあまり意味がないけど、テストしやすさのために SOLID 原則とかを意識した設計を行うのは意味があるのかなあと思います。
テストしやすい = 良い設計とは限らないけど目安にはなるはず。*3

他にもいろいろとディスカッションのネタはありましたが、他の人がまとめてくれるのを期待して割愛。
TDD 実践してないけどみんなでディスカッションするのはとても楽しかったです。

主催の @kyon_mm さん、会場提供頂いた株式会社インターファクトリーさん、 中の人の @susumuis さん、参加者のみなさん、ありがとうございました!

*1:ディスカッション中に疑問がまとまりました

*2:テスト駆動開発による組み込みプログラミング』での LSP の説明はちょっと苦しいかなあと思いますが…

*3:全部 static メソッドでも、グローバル変数ばかりでもテストしやすくできますよね