テスト駆動開発っていいよね

プロダクトコードをいじる前に、まずはテストコードを書いてから、プロダクトコードを書きます。
最初のプロダクトコードではテストは落ちるけど、一通りいじり終わってから、テストをもう一回流して、テストが通ったら出来上がり～

テストコードを先に作っているから、テストしづらいプロダクトコードにはならないはずです！
そして、保障したい動作も振る舞いも全部テストコードに書いておけば、境界値周りのプロダクトコードの動きも心配要りません！

テスト駆動開発は素晴らしいですよね！ぜひぜひ開発の現場で実践したいですよね！

あ、プロダクトコードとテストコードが長いので、これからソースとテストを略させてください。テスト駆動開発もTDDと略させてください。

でもうちじゃ無理だ、と思ったりする？

うちの現場はカッチカチな密結合のレガシコードばかりで、TDDはAPI設計の段階から気をつけてやらないと無理だろう、と思って、実際始める前に諦めていませんか？

実は、いくつのユニットテストパターンを適用することで、密結合なレガシコードでもTDDでやっていけるかもしれません。

以下では、二部構成でその裏にある基本的なテスト戦略と、実際のパターン紹介と適用場面を順に説明していきます。

この記事は主にテスト戦略に着目します。
パターンの方は実際のコード適用例を交えて説明していきたいと思います。

密結合しているコードのうち、テストしたい部分(SUT)と、依存されている部分(DOC)をまず見分けます。
本命(SUT)とその周りの親友たち(DOC)をちゃんと区別して、外堀を埋めてから本命を落とす、というのが基本的なコンセプトになります。

うーん、なんか恋愛ゲームっぽい説明ですね。でもしっくり来るから恋愛ゲームを例に説明し続けます。

SUTの制御は普通、SUTの外部向けメソッドを使って、引数の値で制御します。
外部向けのメソッドだけで制御しきれない場合、もしくは制御するためのメソッドがない場合、DOCの制御ポイントを使います。

恋愛ゲームを例に説明すると、こんな感じになります。

攻略キャラとの会話をこなしつつ、周りのイベントをそれっぽい方向に持っていけば、狙いのエンディングに行けるはずです。

SUTの観測も普通、SUTの外部向けメソッドを使って、戻り値が期待した通りかどうかで観測します。
外部向けのメソッドでの観測が不十分な場合、もしくは観測するためのメソッドがない場合、DOCの観測ポイントを使います。

恋愛ゲームを例に説明すると、こんな感じになります。

攻略キャラとの会話や立ち絵だけでは分からない好感度増減は、ヘルプキャラに聞けば多少は分かるでしょう。

上では、外堀を埋めるという表現使ってましたけど、厳密にいうと、SUTに、外堀は埋まったように見せるです。
何故かと言うと、DOCに必要な制御用メソッドと観測メソッドが揃っているとは限らないからです。

実際、SUTとDOCとのイントラクションはメソッドベースがほとんどなので、DOCと同じAPIを持つ何かを、SUTから見たDOCのポジションに置けば、DOCによる制御と観測と同じ効果を達成できます。

このDOCと同じAPIを持つ何かを、Test Doubleと呼びます。これはあとで説明するテストパターンの中心となります。

恋愛ゲームを例に説明すると、こんな感じになります。

例えば自作自演でも、格好よく不良を撃退したところを見せたら、攻略キャラの好感度も上がるのでしょう。
若干クズな主人公ですが、ここは気にしないでおこう…

テスト戦略を簡単に説明するつもりでしたが、意外と長くなりました。

というわけで、パターンは次回(明日)の記事で説明していきたいと思います。