dotkuwaのコメント: Re:始めにテストをするためには (スコア 1) 20
あなたの抽象を語るに足る、何も提示されていません。
ですので、あなたの抽象については、ここでは議論できません。
アナウンス:スラドとOSDNは受け入れ先を募集中です。
あなたの抽象を語るに足る、何も提示されていません。
ですので、あなたの抽象については、ここでは議論できません。
何でも何も、やって見ればわかりますが
>Google等に当たるほうが適切・確実です。
>むしろこれまでそんなことすら行わず、ひたすらオレオレ解釈をこじらせて
>トンデモ理論を垂れ流していたという事実が噴飯ものです。
では何も言っていないも同然です。
あなたの「原文」はどこにあるのでしょうか。
あなたが自分の言っている事を
とんでもだと言おうと、その根拠が、自分はgoogleの側である、だけでは
お話になりません。恥を知りなさい。
ソフトウェアについて考える科学では、
・依存関係は大事だ
といった様な、荒い粒度の原理と、
・Reserved for future use. Must be zero.
と言った様な、細かい粒度の原理の間に、
絶対に基本原理になり得ない、上手く行く範囲を定めないと
詐欺になる谷間があるのでは、
と思う様になりました。
基本的な話でもなく、具体的な話でもないから
・ある場合は正しく、別の場合は間違う原理
**しか**生まれない粒度の原理の範囲があるとしか
思えません。
ーーーーーーーーーーーーーーーーーーーー
たとえば「制御の反転」(Wikipedia 日本語版)ですが、
これは基本原理の谷間に位置する粒度の原理で、
ある場合は正しく、別の場合は間違いです。
あなたの「原文」に沿って考えなければいけないのですか?
後学に値するなにものも出ません。前提となる「原文」が偽なのですから。
>観ております。
#4157527 の発言があなただとするなら、
そこが焦点です。
計算をすると情報が増える方向のものは、どう増えるかを考えた後でないとテスト方針すら
定まらず、「初めにテストを書け」と言われても困るし、そうしないと不正解だと言われても、
それに従うわけには行きません。
>第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
でも構わないのでしたら、議論は不要です。
なぜ議論になったのかと言うと、
>第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だという主張が主流だったからに過ぎません。
あなたを糾弾したいのではないのです。
ソフトウェアに関するどんな分野でも無条件に、
>第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だと主張していた人間の名誉を下げたいだけなのです。
どうか理解してください!!
>ここ実は大事なところで、テストファーストであってもテストをするのは「後から」なのです。
>テストを予め作っておくか、後付けで作り出すか、そこが違っているのです。
>
>まずこの時点で、テストファーストには悪意があるかのような所見は、誤った前提に基づく曲解だと断言します。
>大体チームの生産性を下げるように作用する方法論が、いつまで経っても手法としては残り続けているわけないでしょう
この様な話は初めて知りました。
確かに誤った前提でした。ただし、あなたの言っている事が主流かつ定説なら!です。
どうなのでしょうか?
たしかに美しいいいぐさですが、本当にそれが主流かつ定説なのでしょうか?
問題点として、
・それではテストファーストは目新しくも何とも無い手法に過ぎなくなる
点が有ります。
初めからその言い方なら、誰も文句の付けようが無かったと思います。
ただ、箸にも棒にもかからなかったとも思います。議論の対象、注目の対象になったのは、
筋違いの主張が有ったからに他ならず、あなたの言い方ではそうならなかった筈です。
まるで、歴史修正主義の言い方に見えます。
>分割統治も疎結合も
>ロクにできていないモノリシックなプログラミングのほうです。
30年前には分割統治は有りました。変な事を言わないでください。
テストファーストというのは、
・離散カオシックな分野を制するCSの研究者レベル
はもちろん、実務者レベルの学識も無い人間が、
・連続系(階差とか)の分野で自分に知見の有る、
初めにテストをする方法を殊更に持ち上げて、
・後からテストをする(彼ら彼女らはその方法を
よく知らない)のを騙して免れようとしている
(自分はもう「テスト」をしたのだから、
今後の「テスト」をするのはお前らだ!)
つまり、
・別の科学の業績だけで、違う科学で有る、
プログラミング分野で、同じ待遇に
ありつこうとしているだけ
では無いでしょうか?
テストファーストだから他のやり方と比べて
少しでも良くなったという事例は見た事が無い
割に、
いつまで経っても手法としては残り続けている
理由は、
その様な利点が、特定の人間にある(他の人間は
寄生され、労力を搾取されてしまう)からでは
無いでしょうか?
> 単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。
何を根拠にその様な考えに至ったのでしょうか?
情報量が減らない計算であっても、愚に陥るかも知れませんが、
それは、どんな手法でも変わらない話だと思います。
設計はします。テストケースも作ります。
ただ、テストファーストはゴメンです。
というだけです。
どうしてゴメンなのかは、自分の仕事の詳細にかかわりますので言えません。
> こちらの認識と合致しているのか、からしてわかりません。
これは仕方ないと、思います。
ただ、実行時チェックは、テストファーストとしてはダメだと言われたのは
事実で、その点からだけでも、自分はテストファーストとは、相いれません。
>テストケースは列挙しなければならず、それを先送りにすることの本質は
>テストを後回しにすることではなく、仕様が固まってないけど頭使いたくないから
>コードを書き始めた、ということではないでしょうか。
この点は、テストファーストではなく、実行時チェックで解決するしか無いと
思います。
テストファーストの方々は、実行時チェックは駄目だと言っている訳ですし、
相容れないと思います。
そもそも論なのですが、
事務計算の様な離散型の計算では、
・カオスはひどいカオス(取り扱い不能になる)にならない
・その代わり、収束させる事が出来ない
様に思いますが、いかがですか?
なにか別のモデルの類推かも知れませんが、失当なのでは
無いでしょうか?
でもその分野の素人は、ある解法を紹介されると、
明示的に「すべてでは無い」と言われない限り、「すべてだ」と思ってしまう
のは事実です。紛れもない事実です。
専門家が、何か「すべてでは無い」と言わない場合、それにも関わらず「すべて」では無い場合、
詐欺だとするべきだと思います。
次回の日記の内容を、タイミングが合ったので載せただけでした。
それほど暇では有りません。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall