第一四半期バタバタしていた。テレビの収録、リハーサル、放送の日程は残念ながら given な条件なので変えられないのだけれど、そうじゃないときは休みを取りやすい。代休も、もちろんちゃんと取れる。部署の上司が取らせようとしてくれるのと、周りが寛容だからだろう。自分ばっかり休んでる気がするけど、気づかないふりして、代休で5日ほど休んでいる。休んでいると、いろいろ余計なことを見るし、考える。以下は、その考えの吐露である。
きっかけはTDDである。が、TDDの話はいい。よくわからないことはあるし、テストの重要性は分かっていつつも、スキルがー、とかでまだあるべき姿に追いついていないところだ。
そこで、あるべき姿とは何か、である。かーらーの、問題の発見/定義と解決である。たとえば（さまざまな紆余曲折を経て）ちょっとしたDBがあり、Webブラウザで閲覧/更新をしたいとしよう。解決策として Django の管理画面を使うことになったとしよう。たぶんテストファーストでユニットテストを書く必要はないだろう。フレームワークのデフォルト機能使うだけなのだから、そんなものテストする工数のほうが多くなりそうだ。
一方で、そのDBに外部からアクセスできるようにし、ロールごとに細かく権限が異なるようなAPIとして提供し、課金までするとなると話が一気に変わる。おそらくは、リリース後に「ACL間違ってました、てへ」は通用しないだろうから、テストファーストかどうか知らないが、何らかの形で自動テストをしたくなるだろう。
この2つは極端だしわかりやすいんだけど、製品やサービスの機能要件、非機能要件、組織のあり方、開発サイクルなどによって、テストの位置づけは全く違うと思う。コンテクスト抜きで問題定義できないし、解決策候補の評価もできない。
ちょっと長いけれど、引用する。
たとえば、エクストリームプログラミング(XP)の方法論でよく知られている
格言のひとつに、「失敗する可能性のあるものすべてをテストせよ」があります。 初心者にとっては、これはレシピとなってしまいます。初心者は何をテストすればよいのでしょうか？オブジェクトの属性値を設定する「セッターメソッド」と属性値を取得する「ゲッターメソッド」のすべてをテストすればよいのでしょうか？プリント文をテストすればよいのでしょうか？見当違いなものをテストするのが関の山でしょう。
熟練者なら、何か失敗するか ― 正確にいえば、何か失敗する可能性が高いか ― を知っています。経験と判断力を備えているので、この格言が特定の状況（コンテキスト）において何を意味するかわかっています。
（Hunt「リファクタリング・ウェットウェア」）
あなたが置かれている状況と、私が置かれている状況が異なり、コンテクストが違うなら、TDD の意味が違う。TDDの解釈に揺れがない、としてもだ。テスト、devops の意味や位置づけもだろう。なんなら、「開発」とか「製品」とかの意味だって違う。「いやいや、テストとは〇〇だ」と言いたいかも知れないけれど、全く残念なことに、そんなことはない。比較的近いと思っている仕事の人達と話しても、違うことあるんじゃないすか？そんなことないすか？ そんなことないと、ここまでドヤ顔で書いてきた私は、ちょっと困るんですけどね。
というわけで、もうちょっと前提条件やコンテクスト明らかにしたほうが、意味のある議論や意見交換ができるんじゃないかな、と思う。私は自分のコンテクストを鑑みて、次のビールを飲む。
