dotkuwaの日記: テストを書くのは二の次 5
日記 by
dotkuwa
必要な値の数(テストをする)≧必要な値の数(計算をする)
だと思います。
ですので、
・テストを書く
のは二の次で、
・テストをするに相応しい数の値がそろっている地点を作る
のが肝要ではないでしょうか?
とくにクレデンシャルなどは、実計算をする際にはまず、
不要なので無視されますが、テストをする時には絶対に
要る値だと思います。
後、文脈に関するフラグなど、フラグにせず文脈自体を
使えばいいとか言われますが、文脈に関するフラグなども
「テストをする際に必要な値」の1つになる事もあるので、
もし、テストをするなら、たとえ文脈自体を使える時でも、
フラグを使わざるを得ない事も有ると思います。
さらに、
・簡単にする
・簡単にするため、無名にする
と言った改良法は、
・テストをするのに必要な数の値がそろう場所が無くなる
ダメージが有る事が良くあります。
そうなりますと、
・プログラムの改良
は
・即、テストを書ける事
にはならず、
・プログラムの改良を(涙を飲んで)そこそこにする
事こそが
・テストを書ける事
になってしまいます。
ですので、
・テストを書く
事が
・即、プログラムの改良につながる
というのは「嘘」だと思います。
訂正 (スコア:1)
× 必要な値の数(テストをする)≧ 必要な値の数(計算をする)
〇 必要な値(テストをする)⊇ 必要な値(計算をする)
かも知れなかったです。
夏休みの宿題 (スコア:1)
テストの実行に必要なことです。
したがって実際に必要な量よりも多くなるのは仕方ない。
ただテストには、同じ条件で試す必要がないという利点があります。
実際には同じ条件で実行されることが多々ありえるが、同じ条件では同じ結果が返ってくるので実行回数が省ける。
だからテストはした方がいい。
問題はおっしゃるとおり必要な値が多くなることで、後から作ろうとすると大変になるんですね。
だからテストはコツコツと必要になった(条件が指定された)時点で作るべきなんです。
Re:夏休みの宿題 (スコア:1)
コメント有難うございます。
現実のプログラマーは、自分のやっている事を、
・古い、老害だ
と言われる事を恐れます。その恐れは、それにより
実際に仕事が無くなる事から、杞憂でなく実際的な
物です。
さて、現在、プログラミングで「より良い」という
提案は大抵、
・非同期処理の考えが入った時、邪魔をしない様にする。
方向が源泉となっていると思います。
これは、
・部分的な計算が出来る位の値がそろった場合、
→外から観測出来ない文脈で(非同期が可能な状況で)
出来る計算をする。
→非同期を生かすために、そこで使った値は捨てる。
という特徴の有る考え方で、
これにより、CPUとかの速度が頭打ちになっても
あと10年は戦えるという趣旨だと思います。
それに対して、テストでは、
・部分的な計算を9回以下行った場合と10回以上行った
場合で扱いが違い、それぞれ回数が定まった場合に
限り、計算に使った値を参照しなおして、テストをする
必要が有る。
とか、非同期処理の利点と真っ向からぶつかる場面が
よく有ります。
対策案として、
・モデルを整備し、そのセッションで使った値、全てを
取って置き、テストに備える。
などというのも有ると思いますが、それは、
・手続き型言語の亡霊である。尻尾である。
・同期を取るのと同義で、非同期の性能を毀損する。
とか言われ、やはりぶつかります。
つまりテストは、
・それをするとプログラムが(現代の基準で)良くなる
訳ではなく、
・それをすると老害だと非難されうる(職を失いかねない)
要素な訳です。
「テストはコツコツと必要になった(条件が指定された)時点で作るべき」
とおっしゃいますが、末端のプログラマーでは、
・(非同期だとかなんだとかの趣向含みの)フレームワークが
出来た段階で、「テストをするに相応しい数の値」がそろうか
どうかは既に決まっていて、ON TIMEにテストを作ろうとしても
遅すぎる。
・現在、良いと言われているフレームワークは非同期の性能を良く
しようとする方向を多分に含んでいて、それに反対する行動
(テストを作るを含む)は人類に仇なすものにされてしまう。
という、受けるいわれの無い障碍が待ち受ける事になります。
たしかに、当初より、非同期処理を推進する側の人も、
・非同期処理はテストがし難い
という事は認めている様ですが、それに止まらず、
・非同期処理は自動テストが出来ない、自動テストを禁止する
認識でいるべきで、
それでも「テストを作るべき」とするならば、それらを打破するべきで、
「そちらこそ老害だ」と(人格攻撃も厭わず)非難すべきだと思います。
それ位、おぜん立てをしていただかないと、末端のプログラマー
はテストを書く気にならないでしょう。
Re:夏休みの宿題 (スコア:1)
改善に向けて動いているはずです。
何故非同期で自動テストがしにくいかというと、
どこかでリソースが競合していて順序や回数によってテスト結果が変わるからですよね。
この時点でテストの条件である『同じ条件で同じ結果』というのを満たせないわけです。
理想的には『同じ条件』を作る段階で外からの干渉を除外しなければならないため
本来非同期と自動テストは相性がいいはずなんです。
ではなぜそうなっていないかというと、リソースやコストの都合ですよね。
そのあたりを代替する方向でいろいろ進化しています。少なくとも以前調べた時は。
しばらくは非同期処理の非同期呼び出し部分のテストは結合テストやユーザーテストに回して、
非同期処理の実体部分で結果を調べたり外部への干渉がないか調べたりする程度に捉えておく方がいいのではないでしょうか。
それ以上を望まれるなら、それこそ発言者に具体的な方法を問い合わせたりテストの成功条件を確認した方がよろしいかと思います。
Re:夏休みの宿題 (スコア:1)
>本来非同期と自動テストは相性がいいはずなんです。
自分はこの2つは、
・非同期は良い進むべき方向
・自動テストも良い進むべき方向
・2つ合わせると最悪の方向
だと思います。ですので、
・非同期は、入出力の抽象化、人間の打鍵・クリック対応、
沢山の試行の中で正しいものが多数になりさえすれば良い
ものなどに限定し
・自動テストをしたい領域からは非同期を完全に排除
すべきだと思います。
自動テストに二の足を踏むのは、
・出来る事の範囲が狭いから
で、非同期対応のプログラムの作りが、さらに範囲の狭さを
助長し、し続けていると思います。
そしてその様な、技術を取り入れる・取り入れないと
いった決定は、プログラマーやプログラマーが話せる範囲の人
に言っても何の効果も有りません。
(さすがに、面と向かって話せる人に対して、人格攻撃も
厭わずとは言えません。)
さらに、そういう技術を提唱する人は、かならず人格攻撃まで
含んだやり方をします。かならずです。
蟷螂の斧でしょうけれども、自分が朽ちるまでには、何としても
一矢報いないと収まりません。