アカウント名:
パスワード:
テストケースを列挙 ≒ テストを設計しなければなりません。テストをきっちり設計してからテスト対象本体の開発に臨め、がテストファーストの本質です。テストを設計することで、「上手くいく範囲」も浮き彫りになります。「上手くいく範囲」はテストの設計が決める、とも言えますね。なぜ責任範囲は有限ではなく無限である、と捉えているのでしょうか。屏風から出てこない虎を捕まえることはできません。
既にライオンさんが出てきて、どういう設計でも構わず、初めにテストをしろと言ってきているので、責任範囲が無限である様な印象を受けました。 屏風から出てこない虎を捕まえることは出来ないと、自分も思いますが、「計算をすると情報量が減る」種類の計算では、必ず屏風から既に虎は出た後になります。「計算をすると情報量が減る」種類の計算では、全ての計算に必要な情報が、既に入力値として有り、それらの情報のみから出力値が得られるからです。 「計算をすると情報量が増える」種類の計算が必要な分野にも、「計算をすると情報量が減る」種類の計算を押し付けるのが、テストファ
「計算をすると情報量が増える」ってのは、具体的にどういうことなんでしょうか。そのまま取るなら情報処理にしくじってプログラムの分割統治もマトモにできぬままカオスを放置しているということになり、まったく褒められたものではありません。百歩譲って実際に「計算をすると情報量が増える」としても、遅かれ早かれテストケースは列挙しなければならず、それを先送りにすることの本質はテストを後回しにすることではなく、仕様が固まってないけど頭使いたくないからコードを書き始めた、ということではないでしょうか。だとしたらそれはプロトタイピングであり、プログラミングの前工程だとも言えます。工程としてはそれもアリだし、この段階でテストをしても意味はなさそうです。とはいえ仕様が確立してプログラムを清書する際にはカオスを収束させテストケースを確立させておくことに変わりはないので、そこでテストファーストを適用したらよいのではと考えます。
画面に入力するとその分情報が増えるでは無いですか。常考。 その観点が抜けているから、頓珍漢な事を言っているのですよ。a=f(x,y,z,s,t,u,v,w,,,)みたいな計算ばかりでは無いという事ですよ。 テストファーストだとかは、計算すると情報量が減る場合には有用でしょうけれど、それは40年前からやっている事で、新規性が無いのですよ。昔の人の業績を無視して新規性が有る様に言う所が背乗りだと言うのですよ。 情報量が増える計算の実務を知らないから「頭を使いたくない」だけとか頓珍漢な事をいうのですよ。 ただ、確かに情報量が減る計算がリデュース型なら、増える計算はカオス型なのかも知れませんね。うまい！ カオスの定義から言ってもそれで良いと思います。そのカオスに挑んだのが手続き型言語で有り、皆が欲しかったストライクゾーンもそこなのでしょう。あなた良い事を言いますよね？！
画面に入力するとその分情報が増えるでは無いですか。常考。
単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。あるいは単体テストをスキップして結合テストレベルの結果を得ようとしていませんか。そうなってしまうのはプログラムも単体レベル・結合レベルでの分割統治ができておらずすべてをモノリシックなモジュールで解決するような実装になっているからではないですか。
計算をすると情報量が増える = 画面に入力するとその分情報が増える、というのは要素の追加・仕様の変更・ディシジョンテーブルの拡張・テストケースの追加、という話でありテストファーストを採用するか否かをそれで決める、というのは主客転倒した話です。設計と検証を混同しています。テストファーストであろうとなかろうと、追加されたテストケースには追従する必要があるのですから。その意味で「新規性が無い
> 単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。何を根拠にその様な考えに至ったのでしょうか?情報量が減らない計算であっても、愚に陥るかも知れませんが、それは、どんな手法でも変わらない話だと思います。
何を根拠にと問われたら、与えられた状況からそのように解釈したという回答になります。とはいえ否定をされないということは、妥当な見立てであったと考えてよいのですかね。
そもそもなぜリデュース型の計算か否かで区別を行い、後者にはテストファーストが有用でないとしているのか。ここからして違和感を感じていました。・入力が増えるならテストケースもそれに応じて増やす・更新対象が多岐に及ぶなら影響範囲すべてを精査するただこれだけのことであり、リデュース型の計算の場合と本質的に一体何が違うというのか、主張に説得力が全く伴っていません。
これで仕様の妥
#4157527 の発言があなただとするなら、そこが焦点です。計算をすると情報が増える方向のものは、どう増えるかを考えた後でないとテスト方針すら定まらず、「初めにテストを書け」と言われても困るし、そうしないと不正解だと言われても、それに従うわけには行きません。＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。でも構わないのでしたら、議論は不要です。 なぜ議論になったのかと言うと、＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。では駄目だという主張が主流だったからに過ぎません。 あなたを糾弾したいのではないのです。ソフトウェアに関するどんな分野でも無条件に、＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。では駄目だと主張していた人間の名誉を下げたいだけなのです。どうか理解してください！！
やたらと抽象的な表現を好む割に抽象的な表現を理解できないのだな。
あなたの抽象を語るに足る、何も提示されていません。ですので、あなたの抽象については、ここでは議論できません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
始めにテストをするためには (スコア:0)
テストケースを列挙 ≒ テストを設計しなければなりません。
テストをきっちり設計してからテスト対象本体の開発に臨め、が
テストファーストの本質です。
テストを設計することで、「上手くいく範囲」も浮き彫りになります。
「上手くいく範囲」はテストの設計が決める、とも言えますね。
なぜ責任範囲は有限ではなく無限である、と捉えているのでしょうか。
屏風から出てこない虎を捕まえることはできません。
Re: (スコア:1)
既にライオンさんが出てきて、どういう設計でも構わず、初めにテストをしろ
と言ってきているので、責任範囲が無限である様な印象を受けました。
屏風から出てこない虎を捕まえることは出来ないと、自分も思いますが、
「計算をすると情報量が減る」種類の計算では、必ず屏風から既に虎は出た後に
なります。
「計算をすると情報量が減る」種類の計算では、全ての計算に必要な情報が、
既に入力値として有り、それらの情報のみから出力値が得られるからです。
「計算をすると情報量が増える」種類の計算が必要な分野にも、
「計算をすると情報量が減る」種類の計算を押し付けるのが、
テストファ
Re: (スコア:0)
「計算をすると情報量が増える」ってのは、具体的にどういうことなんでしょうか。
そのまま取るなら情報処理にしくじってプログラムの分割統治もマトモにできぬまま
カオスを放置しているということになり、まったく褒められたものではありません。
百歩譲って実際に「計算をすると情報量が増える」としても、遅かれ早かれ
テストケースは列挙しなければならず、それを先送りにすることの本質は
テストを後回しにすることではなく、仕様が固まってないけど頭使いたくないから
コードを書き始めた、ということではないでしょうか。
だとしたらそれはプロトタイピングであり、プログラミングの前工程だとも言えます。
工程としてはそれもアリだし、この段階でテストをしても意味はなさそうです。
とはいえ仕様が確立してプログラムを清書する際には
カオスを収束させテストケースを確立させておくことに変わりはないので、
そこでテストファーストを適用したらよいのではと考えます。
Re: (スコア:1)
画面に入力するとその分情報が増えるでは無いですか。常考。
その観点が抜けているから、頓珍漢な事を言っているのですよ。
a=f(x,y,z,s,t,u,v,w,,,)みたいな計算ばかりでは無いという事ですよ。
テストファーストだとかは、計算すると情報量が減る場合には有用で
しょうけれど、それは40年前からやっている事で、新規性が無いの
ですよ。
昔の人の業績を無視して新規性が有る様に言う所が背乗りだと
言うのですよ。
情報量が増える計算の実務を知らないから「頭を使いたくない」だけ
とか頓珍漢な事をいうのですよ。
ただ、確かに情報量が減る計算がリデュース型なら、増える計算はカオス型
なのかも知れませんね。うまい！ カオスの定義から言ってもそれで良いと
思います。
そのカオスに挑んだのが手続き型言語で有り、皆が欲しかったストライクゾーン
もそこなのでしょう。あなた良い事を言いますよね？！
Re: (スコア:0)
画面に入力するとその分情報が増えるでは無いですか。常考。
単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。
あるいは単体テストをスキップして結合テストレベルの結果を得ようとしていませんか。
そうなってしまうのはプログラムも単体レベル・結合レベルでの分割統治ができておらず
すべてをモノリシックなモジュールで解決するような実装になっているからではないですか。
計算をすると情報量が増える = 画面に入力するとその分情報が増える、というのは
要素の追加・仕様の変更・ディシジョンテーブルの拡張・テストケースの追加、という話であり
テストファーストを採用するか否かをそれで決める、というのは主客転倒した話です。設計と検証を混同しています。
テストファーストであろうとなかろうと、追加されたテストケースには追従する必要があるのですから。
その意味で「新規性が無い
Re: (スコア:1)
> 単体テストの段階で結合テストレベルの結果を求める愚に陥っていませんか。
何を根拠にその様な考えに至ったのでしょうか?
情報量が減らない計算であっても、愚に陥るかも知れませんが、
それは、どんな手法でも変わらない話だと思います。
Re: (スコア:0)
何を根拠にと問われたら、与えられた状況からそのように解釈したという回答になります。
とはいえ否定をされないということは、妥当な見立てであったと考えてよいのですかね。
そもそもなぜリデュース型の計算か否かで区別を行い、後者にはテストファーストが
有用でないとしているのか。ここからして違和感を感じていました。
・入力が増えるならテストケースもそれに応じて増やす
・更新対象が多岐に及ぶなら影響範囲すべてを精査する
ただこれだけのことであり、リデュース型の計算の場合と
本質的に一体何が違うというのか、主張に説得力が全く伴っていません。
これで仕様の妥
Re: (スコア:1)
#4157527 の発言があなただとするなら、
そこが焦点です。
計算をすると情報が増える方向のものは、どう増えるかを考えた後でないとテスト方針すら
定まらず、「初めにテストを書け」と言われても困るし、そうしないと不正解だと言われても、
それに従うわけには行きません。
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
でも構わないのでしたら、議論は不要です。
なぜ議論になったのかと言うと、
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だという主張が主流だったからに過ぎません。
あなたを糾弾したいのではないのです。
ソフトウェアに関するどんな分野でも無条件に、
＞第一テスト対象たる本体が動くようにならなければ、テストをすることはできません。
では駄目だと主張していた人間の名誉を下げたいだけなのです。
どうか理解してください！！
Re: (スコア:0)
やたらと抽象的な表現を好む割に抽象的な表現を理解できないのだな。
Re:始めにテストをするためには (スコア:1)
あなたの抽象を語るに足る、何も提示されていません。
ですので、あなたの抽象については、ここでは議論できません。