SUT Behavior，Business Behavior

テストのコンテキストで、 Behavior はよく混乱する。 SUT Behavior、Business Behavior とか 名前を付属すれば、少しは避けられるかな。前者は テスト対象オブジェクト(SUT)と他のオブジェクトのインタラクションに焦点に、後者は人とシステムのインタラクションに焦点が当たっている。

BDDのUnit Testing のビューだと、SUT Behavior に注意が向かう。呼び出し側目線でテスト記述することで、SUTのAPIを明らかにする。言い換えると、お隣さん(呼び出し元)とSUTのインタラクションをデザインする。また、モックやスタブの利用は、SUTが他のお隣さんとのコラボレーションがどのように行われるかをテストを記述する。SUTとお隣さん(呼び出し先)のインタラクションをデザインすることになる。

BDDのAcceptance Testingのビューだと、Bussness Behavior に注意が向かう。ユーザの（身体）目線でシステムの期待する振る舞いを明記して、人とシステムのコラボレーションをデザインすることになる。

（名詞よりも）動詞を、オブジェクトよりもオブジェクト間の繋がりを、人／システムよりも、人とシステムの間で繰り広げられる振る舞いに焦点が向かっている。テスト記述は、暗黙的になりがちな、この《あ・い・だ》の振る舞いの関係を、簡潔かつ解りやすく明記することに力を注ぐ。BDDの B ってたぶんそういう事なのだろう。

それにしても、Behavior のデザイン哲学のルーツがどこにあるのかは、未だによく解らん。ちなみに上の事を思索するようになったのは、下記の２冊を読んでいる最中なので

Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))