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

頭の整理

JavaScript, Ruby, RSpec, Node.js, Rails TDDなどに興味があるWeb系SEが学んだことを整理していきます

TDDeXchange in Tokyo 参加レポート - 主にTDDの自殺の所感 #tddex

先月末の話ですが,TDDeXchange in Tokyoに参加してきました.
内容は@kyon_mmさんの「TDDの自殺」という題の発表と,参加者がTDDできる環境のPCを持ち寄って実際にやってみるというものでした.発表を聞いて質問してみてTDDの自殺の意味と危険性,テストダブルを使う時の心得などを自分なりに整理することができたのでとても有意義な時間でした.

当日の流れや概要は以下のリンクでわかると思います.
TDDeXchange in Tokyo #TDDeX - Togetter
TDDeXchange in Tokyo - connpass

参加の経緯としては,RubyRspecJavaScriptとmochaなどでTDDをやったことはあるのですが,社外の方がTDDに関してどういう考えを持ってるかとかどうやって実践してるかが気になっていてなにか得られればいいなーということで行ってみました.

TDDの自殺

一つ目のコンテンツとして, @kyonn_mm さんの「TDDの自殺」という題の発表がありました.スライドは以下のリンクから見ることができます.
TDDの自殺 #TDDeX
以下のエントリも合わせて読むとわかりやすくなるかもしれません.
TDDの自殺 #kyon_mmAdvent - うさぎ組

ここからは自分なりの理解をまとめますが,きょんさんが仰ったこととは違う解釈になってしまってる可能性もあります.つっこみとか質問があればして欲しいです.

アプリケーションドメインとソリューションドメインという言葉が出てきていますが,自分なりに以下の様な解釈をしました.

  • アプリケーションドメイン
    要求仕様で表現される領域とその記述
  • ソリューションドメイン
    アプリケーションドメインを実現するためのロジック.プログラミング言語による記述やライブラリの組み合わせなど

この話の前提としてTDDは開発者を支援するフレームワークであるという定義と,「アプリケーションドメインの記述」=「ソリューションドメインの記述」となるコードが理想だという定義をしています.

前者の定義に関しては@t_wadaさんのTDD BootCampでのお話がわかりやすいと思うので興味がある人はどうぞ.
Ustream.tv: ユーザー brtriver: tddbc tokyo 1.5 基調講演, 日本でのTDD第一人者である 和田 卓人こと、@t_wada さんの講演. コンピュータ...
TDD Boot Camp

後者の定義に関しては形式手法とかDDD(ドメイン駆動設計)とかDSL(ドメイン特化言語)とかDSM(ドメイン固有モデリング)とかのどれか一つでも知っている人であれば納得できると思います.

で,やっと本題の内容(といっても僕の解釈)を書きます.

TDDとドメインの関係

TDDではまずテストコードに達成したいことを表現します.つまり最初にテストコードにアプリケーションドメインを記述します.

その後プロダクトコード(ソリューションドメイン)を実装します.更にその後,プロダクトコードをリファクタリングします.

具体的にはプロダクトコードをわかりやすい表現にしたりメソッド分割をしたりしますが,これはプロダクトコードにアプリケーションドメインの記述を埋め込んでいっていることになります.

TDDの自殺の解釈

TDDをやっているとテストダブル(モックやスタブ)を使う場面がたくさんあると思います.例えば,複数のテストでモジュールAの振る舞いをテストダブルに置き換えて記述するとします.それ自体には問題はないと思います.

ですがテストダブルに本来ないような振る舞いをさせてしまったり,テストダブルにしたモジュールのテストが不十分だった場合はプロダクトコードに目的の振る舞いが含まれなかったり意図しない振る舞いを埋め込んだりすることにつながります.

そういう事態をTDDは引き起こしやすくて,それが起こってしまうとTDDが自殺している状況になるのだと思います.他にもいろいろな例があるんだと思いますが,テストダブルの例は自分も経験があるし個人的にわかりやすかったです.

解決策

発表はTDDの自殺の問題提起まででした.テストダブルに関しては,テストダブルにしたモジュールやクラスのテストをしっかりするしかないのかなと思っていて,そういう質問をしてみたんですがやっぱり現時点ではそうするしかないっていう結論になりました.
ですが,きょんさんはモックやスタブを使わないテストフレームワークを作成中と仰っていたので個人的にはとても興味がわきました.


主催の@kyon_mmさん,会場を提供してくださった株式会社ドリコムの皆様,当日の参加者の皆様,貴重な機会を提供していただいきありがとうございました.

当日やったTDDの課題に関しても書きたかったのですが,長くなったので別のエントリにします.
発表を聞いて議論できたことで当初の目的はほぼ達成できたので書きたいことは書いてしまったかもしれませんが.