【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】

>>857
というより、C0テストすら知らない奴が話を混乱させていると思われ。

>宣言していない識別子が出ているだけならC0で発見できるだろ。
無理言うなｗｗｗ

全てのコード上の式およびステートメントが1通り以上実行されているのだから、
宣言していない識別子が出ていれば当然発見できるでしょ。

ああ、やっぱり知らないのか。
C0君は動的言語について、すこし勉強してから来るように。

>>861
宣言されてない識別子を使った時点で、宣言されたことになる言語はごまんとあるわけだが

>>848が意図的にtypoという別の変数に入れたものなのか変数名を間違えただけなのかを明確に区別できる方法があるなら教えてほしい

条件1: 静的型言語L1で記述されたプログラムP1に対して、
　　　　テスト基準C0を満たすテストケースT1を実行し、エラー0の結果を得る。

条件2：動的型言語L2で記述されたプログラムP2に対して、
　　　　において、テスト基準C0を満たすテストケースT2を実行し、エラー0の結果を得る。

また、P1およびP2は同じ仕様に基く、内容も1対1に対応するものとする。

一般に動的型言語のほうが有意にテスト量が大きくなることを示すためには、
以下の1いずれかを満たす必要がある。

結論1: | T2 | が | T1 | よりも有意に大きくなる。
結論2: P1もP2も未発見のバグを含んでいる可能性は残っているが、
　　　　　条件2で未発見のバグが同様の実装をされた条件1で発見されるものが
　　　　　条件1で未発見のバグが同様の実装をされた条件2で発見されるものよりも
　　　　　有意に大きくなる。

さあ、結論1でも結論2でも、実例なり根拠なりを示してくれ。

3行にまとめて欲しい

>>863
で、その宣言されていない変数を使っても、仕様通りの結果が得られるわけか？
C0を満たすというのはそういう意味なのだが。

>>864
仕様で求められている結果が得られるかどうか。つまり、>>848の例でいえば、
仕様は「2を印字する」であるはずだから、>>848のコードは仕様を満たさず、
テストでエラーとして検出される。

結論： 動的言語でテストが増えると言ってる奴は、C0テストの意味すら知らない香具師だった。

>>848が端的に表現してるのに・・・

>>869
>>848を通してしまうようなテストはテストとは言わない。
C0テストで一発で発見できる。

宣言されていない変数を使っても、仕様通りの結果が得られるパターンなんか無限にあるだろうに

>>871
そう。宣言されている変数を使っていても、仕様通りの結果が得られるパターンなんか無限にあるだろうに。

しかもC0は条件の組み合わせや通すコードの順番には無頓着だから、
入力と結果の組み合わせは網羅できないんだがな。
C0通ると全ての場合について網羅されると勘違いしてるのかな。

宣言されている別の変数を使っていても、仕様通りの結果が得られるパターンなんか無限にあるだろうに。

>>873
単純なtypoや実装されていないメソッド叩いたりするのは検出できるだろ。
>>848がまさにいい例だ。

>>853

>>876 >>854読め

//ほらよ
type=arg1;//arg1,arg2:入力値
typo=type*arg2;
if(type>200)print('big');

今どき境界値すら試さないテストしてるマヌケがいるのか？

>>878
で、C0を満たすテストケースは？

// これは？
int type, typo;
type = arg1;
typo = arg2;
typo = type * arg3;
if (type > 200) print ('big');

これと>>878との本質的な違いは何だ？

>>878
それは境界値テストで発見されるだろ。テストの初歩だよ、初歩。

存在する境界値を網羅するのは、C0の範疇じゃ無いんだが・・・

(arg1='2',arg3=5)なんてのが飛んで来るかもしれないのが動的言語。

>>883
そうだね、C0の範疇じゃないね。でも実際には境界値はまっさきにテストする項目だよね。

お、C0で全部検出できるって言ってたのにいつの間にか話を変えてるな

>>884
可変長パラメータは静的型言語はデフォルト値が与えられるけど、どのみちC0じゃ検出できない。
ところでいつから動的言語が比較対象になったんだ？
てっきり動的型言語が比較対象だと思っていたのだが。

>>886
全部検出できるなんて言ってないよ。必要なテストの量に有意な差は出ないとは言ってるが。

>>843
>typoやメソッドの有無によるバグはC0で完全にカバーされるだろ。

>>865
「100%のカバレッジを達成しないと、タイポや実はメソッドが存在しない等の可能性が残る」
もはやこれだけで、結論1を満たしていると思うのだけど。
カバレッジ100%を保証すべきというのは分かるけど、普通は（特に個人だと）そこまでやらんのではないか。

あと、一部の動的言語では
・実行中に関数が定義
できたり
・実行時にメソッドが定義
できたり
・実行中にほとんどのクラスが使っているような基本的なオブジェクトの振る舞い(RubyならNilClassとか)を変える
ことができたりする。
この前提だと、結論1か結論2(もしくは両方)を満たさざるを得ないのではないか？
特にこういう機構をふんだんに使っている（メタプログラミング）場合、テスト自体が困難を極めると思う。

>>887
静的型付けの動的言語については考えていなかった。
すこし反省している。

> 特にこういう機構をふんだんに使っている（メタプログラミング）場合、テスト自体が困難を極めると思う。

ヤバい箇所が機械的に限られるJavaのほうが
どこが地雷源かわからないRubyよりましだと思うんだ

>>884
そして、'2'*5を評価した値が10の実装もあれば、"22222"の実装もあったりする。

849がｽﾙｰされてﾜﾛﾀ

結局のところ小規模か大規模かの問題じゃないよな

強いて言えば、型指定のある言語の方が
IDEの補助を受けやすいってのはあるかな。

>>890
そうなんだよな。テスト屋殺すにゃevalの1つもあれば十分なんだよ。

>>893
俺もC0で型チェックのかわりは無茶だと思うが、
'2'*5が10か'22222'かは言語仕様で一意に決まるだろｗｗｗ

つーか、どっちになるか知らずにコード書く馬鹿は
どんな言語使ってもどのみちバグまみれだって。

>>898
前者は一見して期待した結果になるからやっかいだ。
まぁ、一意に決まらない言語もあるが、それはおいといて。

>>898
演算子オーバーロードを忘れてる

もう動的型言語とか関係ないな

つまり、なでしこ最強

scalaに乗り換えますた。

まあLLにこだわるこたないからな
erlangとかも面白いしね

>>843 C0で全部カバーできると言い
>>847 C0で発見できないバグの実例を見せてくれとまで言ってたのに
微妙にそういう話が出てくると
>>883 境界線は真っ先にテストする項目だろと全部カバーできる発言を覆すあたり
負けず嫌いがこのスレに常駐してるようですね

結論は>>890だな。
C0基準でもカバレッジ100%のテストをする香具師なんて滅多にいない。
静的言語はコンパイラさえ通っちゃえばコマンドライン2-3度叩いてヌルポ出なきゃOK。

つまりぬるぽが出ない言語ならなんもしなくてOK。

さすがに引いた