TDD専門職？ １

どの様な話？

私はこのブログ中で、TDDについて批判的でした。

TDD自体は良い所も有るのかも知れませんが、多分、その実際の運用が、私にとって批判の対象となり得る物となっているのだと思います。

実際の運用

現在、行われているTDDの運用は、

• 束構造因果ダイアグラム中、「一番小さいプログラムの部分」のsmallなテストを集中してやる
• それ以外は等閑視する

以外、解釈のしようが無い事になっていると、私は認識します。

そして、

• 「一番小さいプログラムの部分」のsmallなテストは、
• Well-defined（Well-defined Wikipedia 日本語版）な部分で有り、
• 非常に明確で「科学的」な取り扱いが可能

であるとも思います。

これを独り占めしようとするから、批判を招くのだと思います。

TDD専門職？

ずっとプログラマー一筋でやって来た私ですが、定年後、（書いても「そんなに言うなら自分でやってみろ」と言われ難くなったので）ブログを書くに当たり、

少々高いのですが、ビジネス雑誌をとる様になりました。初めはトイレ専門のiPadを設けようとしましたが*1、やはり運用しづらく、紙の雑誌とセット販売とし、さらに高額になったのは計算外でした。

それはさて置き、

ビジネス雑誌（Webのみも含む）では、「ジョブ型雇用」（ジョブ型雇用 Wikipedia 日本語版 他）と言う
雇用形態が日本で模索されていると書かれています。

批判となりがちな、TDDの運用を是正し、批判を緩和する為には、

• 現在のTDDの運用が、総合職＋研究職＋Well-definedのタコツボ

を指向しているのを改め、

• TDD専門職としてジョブ型雇用の先駆けと位置付け、
• ひたすら「一番小さいプログラムの部分」のsmallなテストに専念してもらう

職制を創出する事をこのブログで提案いたします。

これにより、TDDの運用の非難を緩和できると私は強く確信します。

結論

これからも「TDD専門職」職制の不在により、プログラミングが嫌いになる人は存在し続けることでしょう。  

*1:1DKでそれ程狭い訳でも無いのですが、色々置き、その結果、まともな椅子がトイレにしか無い為、トイレの前に雑誌を積んで食卓としている

smallで無いテストの困難さ ２

合流点と来れば

合流点と来れば、交絡についても言及しないといけないと思いますが、

• 大データへの読み書き＆保全（「JavaScriptが大変　２」参照）

をするプログラムを、オニオンリングとかの形式にして、

• 値作成（ドメインモデルに関連有り）
• 大データへ読み書きする

に分けたとしても、

（下図は、『ジューディア・パール,ダナ・マッケンジー. 因果推論の科学　「なぜ？」の問いにどう答えるか (Japanese Edition)』、「交絡因子　ー　隠された第三の存在」 より）

「保全」が上図Z、「読み書き」が上図X、「値作成」（ドメインモデルに関連有り）が上図Yとなり、

大データの保全の為の値作成（Z→Y）は無くなっていない

というのが典型的な例だと思います。

「読み書き」と言う問題（例えば、RDBの”技術的・技巧的な”所）から目を背けても、大変な部分（保全）の問題は消えないと言う事だと思います。

因果ダイアグラムについての疑問点

上図では、

• Z→Xも、Z→Yも、X→Yも

矢印で書かれていますが、これは因果関係を表しています。

ところで、擬似相関（擬似相関 Wikipedia 日本語版）という言い方も有ります。

• X→Yは、因果関係で無い（相関で有る）

とする言い方です。

本文書でのX→Y（「読み書き」→「値作成」）は嘘の因果関係（p<0.5 ?）とでも言うのでしょうか？

通常、

• 「相関関係は因果関係を含意しない」（擬似相関 Wikipedia 日本語版）

はずですが、逆に

• 「因果関係は相関関係を含意する」

と取れる様に思えてなりません。

この点について何処にも書いて有りませんし、聞ける様な所も知りません。

疑問です。

結論

これからも「smallで無いテストの困難さ」でプログラミングが嫌いになる人は存在し続けることでしょう。  

smallで無いテストの困難さ １

どの様な話？

ソフトウェア開発での、束構造の因果ダイアグラムは、

• 上限が「システムを作ろうとする発端」で、
• 上限方向のグラフの半分が「原因が、複数の独立・直交した部分原因に分かれる」過程で有り、
• グラフの真ん中の一番「太った」部分に、一番小さいプログラムの部分が置かれ、
• その後、下限方向のグラフの半分にて、より大きいプログラムの部分へ集約されて行き、
• 下限が「システム完成」を表す

と想定されますが、

一番小さいプログラムの部分が、より大きいプログラムの部分へ集約されて行くというグラフは、
合流点（合流点 (統計学) Wikipedia 日本語版）を成すのでは無いかと思う様になりました。

それは何か悪い事が有るのでしょうか？

そもそもsmallやlargeに限らず、大抵の自動テストは、サンプリングを基本としていると思います。テスト対象の母集団から、一部を抜き出して検証します。

しかも、合流点ですよ、皆さん！！！

合流点バイアスが起きる非常に有望な苗床としか見えません。

後、経験（n=1）からの話ですが、

後、経験（n=1）からの話ですが、

• 所与の原因から結果として得られる、小さいプログラムの部分（複数）を、
• 集約する事で、より大きいプログラムの部分になるが、
• その際の気づきとして、
• 小さいプログラムの部分が、原因を十全に実現せずに結果としている場合が有り、
• より大きいプログラムの部分を構成して見て初めて不足が分かる

事が良く有ります。

小さいプログラムの部分（＝small なテストの範囲）では合格だったにもかかわらず、全体としては不合格になり得るという、話です。

これもサンプリングを基本としている自動テスト、特にsmall な自動テストでは気づかない可能性が大です。

要するにsmall な自動テストが「出来る」のは、

• 「完全に理解した」

状態で有り、よりlarge 方向へのテストで、

• 「なにもわからない」、「チョットデキル」

状態に移行するので、small で無いテストは困難なのでは無いでしょうか？
また、それには、この視点での合流点バイアスが関係している様に思えてなりません。

結論

これからも「smallで無いテストの困難さ」でプログラミングが嫌いになる人は存在し続けることでしょう。  

「四の五の言うな」 ２

テストも「原因」の1つだったとしたら、

テストも「原因」の1つだったとして、

「プログラムの部分」が持つ「原因」の数に限りが有るとして、

一番小さい方の「プログラムの部分」の様に、数に余裕が有る場合と違い、

もっと大きい方の「プログラムの部分」で、「原因」の数を使い果たしている部分の場合、

テストにより、別の「原因」を諦めないといけなくなるので、手動テストで代用している、

とか無いでしょうか？