class A => class B => (DB呼び出し) みたいな感じになってる時に、Aをテストしたい時にBをstub/mock したいんだけど、そのstubが正しいことって (特にRubyだと) 往々にして信頼できなくなってしまう。

信頼度を上げるために、この stub/mock を B側のテストと連動させられないか? ということを考えた。

例えば B のテストに、「状態 X において、引数 Y で呼び出すと、戻り値 Z を返す」みたいなテストがあるとする。この時、A のテストにおいて、
・状態 X をインポートし
・Bを「引数Yで呼びだし戻り値Zを返す」というふうにstubする
として、これがBのテストと連動していることが検証できれば、そのstubは信用できるといえる。

... とここまで書いて、これは Consumer-driven Contract (CDC) Testing そのものなのではということに気づいた。

CDC Testing は (僕の現在の理解だと) ふつう複数サービス間のテストに使われるが、概要は以下のようなものだ:

サービスAがサービスBのエンドポイントを呼び出すとき、
・状態 X において (provider state)
・Y というリクエストパラメータで呼び出すと
・Z というレスポンスを返す
というものを、契約(Contract)として定義する。この契約をもとに、サービスAはサービスBへのリクエスト部分をstub/mockしてテストでき、Bはこの契約を守れていることをテストする。

CDC Testing は実践したことがほとんどない(一応ちょっとはあるけど)ので正直そんなに知見がないのだが、これはこれでまあまあ効果のわりにコストが高くなりがちらしいとは聞いたことがある。が、プロセス内でやる前提に工夫したら低コストで効果を得られる感じにできないかなあ。

それとも、名前付いてないor別の名前がついてるだけで、テスト駆動開発的には当たり前の手法だったりするのだろうか? 少なくとも Ruby/RSpec だときいたことがない。

(トップ画像は、みんなのフォトギャラリーからgolchikiさんのを再びいただきました。"契約"の様子)