ジョブの定義
この話はもう少し、深掘りして見ようと思います。
ジョブ型雇用となると、
- ジョブの定義
が必要です。
- これこれをしなければならない
- これこれをしてはいけない
などです。
TDD専門職を雇うとすると1番目に引っかかるだろう点
TDD専門職を雇うとすると1番目に引っかかるだろう点は、
- テストの表現方法
だと思います。TDDの専門職になりたい様な人は、たいてい、
- テストは関数呼出しで無いとダメ
- 関数は外部から動作を観測出来てはダメ
と言い張ると思います。しかし、
- 全ての「一番小さいプログラムの部分」を、
- 外部から動作を観測出来ない関数呼出しのみで、
テストが書けるのかの議論が必要です。
外部から動作を観測出来る関数なら、話は別です。
引数に読み書き可能なフィールドを持ったオブジェクトを据え、
やった事、使った変数などを全部、そのオブジェクトに持たせれば、かなりのテスト（多分、全てのテスト）が可能となると思います*1。
もし、
もし、
- 外部から動作を観測出来ない関数呼出しのみで、
- 全ての「一番小さいプログラムの部分」を
- テスト出来ない。
事が理論的に証明出来た場合、
TDDの専門職を雇う際に、ジョブの定義として、
- 外部から動作を観測出来ない関数呼出しのみでは、
- 成果とならない場合が有る。
そして、
- 外部から動作を観測出来ない関数呼出しのみでのテストで
- 成果と認めてもらいたい場合は、
- その妥当性の証明は認めてもらいたい側に有る
などと、ジョブを定義しないといけないかも知れません。
TDDを推進していた人から聞いた事
TDDを推進していた人から聞いた事として、
- ログやアサートを後から見て、テストとするのは誤りだ
とする意見が有ります。外部から動作を観測出来てはダメと言う主張だと思います。
しかし、
- 外部から動作を観測出来ない関数呼出しのみで
全てのテストが出来るかどうかの検証は出来ていず、自明でも無いと思いますので、ジョブ型雇用には、困難が有ると思います。
もちろん、困難はこれ一つでは無いと思います。
結論
これからも「TDD専門職」職制の不在により、プログラミングが嫌いになる人は存在し続けることでしょう。
*1:ただし、これでは「レキシカルスコープとか台無し😅になるでしょう。
