どの様な話？
プログラミングにはテストが必須です。それは正解との適合性の検証です。
そして多分、テストはプログラミングの素養がなければ書けません。
それは、
- テストが出来る様な対象は有史以来、プログラミングが初めて
だからです。プログラミングが成立する前は、テストも有りませんでした。
ですので、プログラミングが嫌いな人は、テストも嫌悪し、しかしそれを望むのです。アンビバレントというやつでしょうか？
何が問題か？
（自然言語で書かれた）要件定義書を元にプログラミングを作るプログラマーは、永続的なテストが書けないのです。
状況を模式的に言うなら、
- 要件定義書とは、いくつかの必要とする点を指定したもの
- プログラミングとは、それにふさわしい滑らかな曲線を描くこと
- ふさわしい滑らかな曲線は、複数存在する
- 「無限」で無く、「複数」なのは、プログラミングの技術的制約のため
ですが、そういう状況下でプログラマーは、
- そのプロジェクトの原理原則を極力遵守し
- 複数のふさわしい滑らかな曲線のどれになっても（まぁ）大丈夫な様にしつつ、
- その内の1つの滑らかな曲線を（半ばあてずっぽうで）選び実装する
という知的作業をします。
どうにもならないのか？
この時点で、コストをかけて永続的に使い得るテストを書くのは無駄です。
1回使い捨ての簡易なテストをして、要件定義書の発注者側に近い（上流の）人に渡します。これは定義された正当な手順です。
その後、上流の人間が、
- この（あてずっぽうで選んだ）滑らかな曲線が良ければ、（多くの場合テストの専門家が）永続的なテストを書き
- そうで無いならその旨を下流に返す（このことを「不具合」と称することが有りますが、不本意では有ります。）
とすることでしょう。上流に近い人間は、プログラミングの素養の他に、どの「滑らかな曲線」が正解か判定する素養も必要です。
どの「滑らかな曲線」が正解なのかを本当に知るのは発注者で有り、上流の人はその代弁人として、正解を判定します。
やはり例外は有ります
運用コストが高いシステムで動かしているプログラムを、低いシステムで動く様に変更する場合、テストはかなり容易になります。
- 前のシステムの入力→出力と、全く同じな入力→出力になる様
にすれば良いからです。
多分これが理想なのだと思います。
あらかじめ正解が（要件定義書が）プログラミングとして書き切られている場合です。
もちろん現実はこれとは合致しない場合が大大大多数たと思います。
結論
プログラミングの素養の他に、どの「滑らかな曲線」が正解か判定する素養も持った人がいない場合、永続的なテストは書けません。
そして、一般のプログラマーはまずもって前者しか持ちません。それは技能の問題では無く、立場の問題です。
そうなると、どちらの素養も無い人はお手上げになり、
これからも「テストを書いてくれない」事でプログラミングが嫌いになる人は存在し続けることでしょう。
