【TDD】テスト駆動開発【TestFirst】

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2010/09/19(日) 21:26:12
テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
2013/04/29(月) 21:41:33.37
>>252はアホ
2013/04/30(火) 15:46:55.50
コンソールがあって、さらにはprintfとassertが使えるなら、xUnitも使えるだろうが
256アホ
垢版 |
2013/05/01(水) 05:26:40.17
CUnitとかCppUnit etcって、makeする時に実行されるもんじゃないの?
バイナリ実行すればコンソールに表示されるようなもんなの?
257アホ
垢版 |
2013/05/01(水) 08:04:01.43
CUnit入れてコンパイルまでは通したけど、全部FAILEDになるぜドチクショウ
スレ汚し失礼しました
2013/06/27(木) 08:16:11.07
>>247
stubあんのにそんな長文、恥ずかしくないの？
2013/07/12(金) NY:AN:NY.AN
TDD始めてみたんだが、暗号化するメソッドと複合化するメソッドがあって、あるデータを暗号化して複合したらもとのデータ戻るってテストはどうやって書くのがいいの？
2013/07/12(金) NY:AN:NY.AN
既知の平文と暗号文の対を用意して
「平文→暗号化メソッド→暗号文」 というテストと
「暗号文→復号メソッド→平文」 というテストをすればいいと思うよ
2013/07/22(月) NY:AN:NY.AN
>>260
既知の暗号文無いから暗号文を求めようとしても、手で計算するのがものすごく大変。
計算機で計算しようとしても、その数式がコードそのものだから本末転倒なんだよね。
2013/07/22(月) NY:AN:NY.AN
知らんがな(´・ω・｀)
いかに大変でも期待通りの暗号化処理が正しくなされてるか確認するためには最低1回は答え合わせをせざるを得なかろうよ
2013/07/24(水) NY:AN:NY.AN
>>261はTDD以前に自分が何をテストしなければならないのかすら
分かってない気がする
2013/07/28(日) NY:AN:NY.AN
>>263
もしかしてこういうのってテストしなくてもいいの？
2013/07/28(日) NY:AN:NY.AN
TDDのテストは開発者が設計実装を駆動するためのホワイトボックステストで、
開発者がテストとコードを両方見て主観的にコードが正しいことに確信を持てる程度のものにする。

暗号化とか神経質にならざるを得ないかもしれないが
その品質用テストを用意するのはTDDの範疇外というだけで
要らないものではないと思われ
2013/07/28(日) NY:AN:NY.AN
仕様書に入出力（平文と暗号文）のサンプルくらい記載されているもんじゃないのか
それコピペすれば最低限のテストはできる思うけど

入出力が分からないんじゃTDD以前の問題だわ
2013/07/28(日) NY:AN:NY.AN
>>265
そうなのだろうが、暗号化するコードなのに肝心の「暗号化できているか」をまったく調べることができないと、コードの正しさに確信が持てないんだよなあ。
というかTDDのテストってブラックボックスじゃないの？
2013/07/28(日) NY:AN:NY.AN
>>266
やっぱり出力を先に手計算しといたほうがいいのかな？
add(1,1) == 2 になることを調べるテストだって、右辺の2は前もって人間が計算してるわけだし。

ただ今回の場合は簡単な解が無くて、暗号化計算してわけのわからん値になったもの同士を比較するテストをして通っても、そのメソッドが正しいという確信が得られるような気がしないんだよなあ。
そんなテストよりは、暗号文の特性、複合すると元に戻ることとかを調べたほうが直感的な気がしたんだが…なんかもやもやする。
2013/07/28(日) NY:AN:NY.AN
>>268
たとえば解の候補が３パターンあるとして
①顧客の解（要望）…AESで作ってほしい
②設計者の解（仕様書）…Twofishを採用しよう
③>>268の解(実装)…分けわからんが0xABCDでビットマスクで実装すればいいんだよな？

で、>>268がやろうとしているのは「③」をパスするテストコードを書くってことだ
それをパスすることに意味はあるのか？　「①＝②＝③」なら問題ないが
2013/07/29(月) NY:AN:NY.AN
>>269
どういうこと？
すまん、さっき「解」っていったのは、メソッドの返す値って意味で。
複合すると元に戻るっていうのを調べるテストは、それをパスする他のアルゴリズムがあるから、仕様をテストが表現できていないって感じの意味か？確かに、そう考えるとやばそう…。

だが手計算で計算するのが大変で、プログラムのテストというより、自分の計算のテストになりそうなんだけど。結構時間もかかるだろうし。
2013/08/01(木) NY:AN:NY.AN
そもそも単体テストってassert(expression)だから、expressionを自分で定義できなきゃやりようがないわな
272デフォルトの名無しさん
垢版 |
2013/10/19(土) 14:06:55.25
マジでどうしたらいいかわからん助けて

encryptメソッドの仕様は
encrypt(text, pass) = salt+aes(sha(pass)+text, pass, salt)
salt=sha(rand)
aesはaes暗号、shaはハッシュ関数のやつ、randは乱数、+は文字列の結合な。
あと、textやpassは空文字でもok

decrypt(crypt, pass)はそれの復号メソッドで、もしcryptにaesの復号エラーにならないようなでたらめな値入れられても、復号文の先頭のsha(pass)が一致しなければ自作例外を投げる仕様。

お前らならどうテストすんの？
2013/10/19(土) 20:41:24.25
レスに書いてあることそのままテストすりゃいいんじゃないの
2013/10/19(土) 21:46:37.57
crypt = encrypt(text, pass);
try {
decrypted = decrypt(crypt, pass);
assert(decrypted == text);
}
catch {
assert(false);
}
try {
decrypt(nonsense_crypt_not_aes_decrypt_error, pass);
assert(false);
}
catch {
assert(true);
}
2013/12/06(金) 15:11:53.63
http://the-little-book-of-busterjs.readthedocs.org/en/latest/doc/column/TravisCI/
276デフォルトの名無しさん
垢版 |
2013/12/26(木) 15:53:04.30
TDD Advent Calendar 2013
http://qiita.com/advent-calendar/2013/tddadventjp
2013/12/26(木) 17:18:52.11
メソッドの名前をリファクタリングで変更するだけで
テスト毎ぶっこわれる動的言語ではTDDは辛すぎる
2014/01/13(月) 10:28:34.81
CUI のアプリを作っているのですが、ユーザーからの入力や、
それに対する出力などをテストしたいです。

ビジネスロジックの方では、入力と出力の関係は既に正しくテストされている前提です。
あくまで、UI の部分のテストの話です。

CUI用のUIテスト自動化フレームワークは何かないでしょうか。


[環境]
Linux
2014/01/13(月) 11:15:01.01
>>278
シェルスクリプト書けばいいだけでは？
2014/01/13(月) 11:19:04.03
追加。入力周りは昔はexpectというtclの拡張コマンドがよく使われてたけど、今はtclなんて流行らないよね…。
たぶん、perlとか、他のスクリプト言語にもexpect相当のライブラリがあるのでは？
281278
垢版 |
2014/01/13(月) 11:42:00.72
なるほど、確かに。
自分の得意なスクリプト言語で作ればいいんですよね。

頭が堅すぎたようです。

ありがとうございました。
2014/01/14(火) 08:16:34.22
TAPを出すシェルスクリプトを書いて
proveでテスト実行とかかな
283デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:33:01.79
テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。
284デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:34:16.46
テストせやかて工藤
285デフォルトの名無しさん
垢版 |
2014/01/26(日) 12:37:38.39
>>283
根本的にOSSというのを勘違いしているから
その後に発言が無意味になってる。
2014/01/27(月) 11:19:03.88
> 最初から通るテストを書いているわけで、結局コードを書いているのと同じ
> レベルになって、バグは入り込むわけだし。

それはテストコードと言えないだろうね
テストが通れば確実にバグってない事が保証出来るコードでないと意味ないよね
ようするに単純なテストを積み重ねていく感じか
2014/01/27(月) 15:53:46.32
仕様に明記されていないことはやらない（コードに落とさない）
仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す
2014/01/27(月) 17:11:28.38
コードをテストに合わせるからバグが減る
テストをコードに合わせてはいけない
2014/01/28(火) 08:16:11.34
TDDで後から実行可能なテストも手に入るのはオマケやで
出来てしまったテストを捨てることもないだろうが
あくまで開発を前に進ませる手段や
2014/01/28(火) 08:17:03.85
> 仕様に明記されていないことはやらない（コードに落とさない）
> 仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

仕様等の出発点からどのように粒度を落としていくか（設計していくか）の方向性として
テストするという観点を掲げているのがケントベックが本で語ったTDDなのだが
この開発の最初に必要とされるであろうステップが
日本語のWebサイト上のいろいろある解説ではびっくりするくらい完全に無視されている
2014/01/28(火) 08:36:37.02
何見て解説してるのかわからんな
292デフォルトの名無しさん
垢版 |
2014/01/28(火) 11:12:20.43
>>290
TDDのそもそもの意味/意図である「テスト駆動」の「駆動」を忘れてるのか知らないのか無視してる奴が多いね。
なんとなくのイメージで「xUnitを使って自動テストをしながらコードを書く」くらいの理解の奴が多い感じ。
2014/01/28(火) 13:08:16.58
Test First と Test Driven はどう違う？
2014/01/28(火) 13:48:03.51
>>293
ざっくり言えば、TDD = Design First + Test First + Refactoring
2014/01/28(火) 15:13:31.12
>「駆動」を忘れてるのか知らないのか無視してる奴が多い

スレタイのせいかもな
2014/01/28(火) 18:22:31.47
BDDと形式手法の違いって？
2014/01/28(火) 18:34:16.93
>>296
形式手法って何？
2014/01/28(火) 21:50:39.87
テストを書くときの気持ちのこと
2014/01/29(水) 10:13:17.67
ぐぐればすぐ出てくるものを即座に質問する
これを脊髄駆動レスと呼びます
2014/01/29(水) 12:52:40.18
>>299
>>296のことなのか、>>297のことなのか
2014/01/31(金) 10:18:11.76
ぐぐれ
2014/02/02(日) 04:03:14.23
こんなスレあったのか
しかもだいぶ前からあるとは

俺はTDDは必要だと思ってる
元々ゴリゴリコーディングして、デバッガー使ったりで人力でテストしてって感じだったけど、
思想を知ってから、あぁこんな洗練されたものがあったのかと思った
昔はテストなんて面倒くさいと思ってたけど、それでも思想を知ってからは無理して身体に覚えさせた
慣れだよね

DBやマルチプロセスとかの問題は言われてるけど、使い分けじゃないの？
有用なときは使い 、効率悪いときは別のやり方
完璧なものなんてないだろうし

なぜ流行らなかったとか別スレあるという事は、皆あんまテストしないのか？
しても後から曖昧にとか？
2014/02/02(日) 07:00:16.31
>>302
TDDはテストじゃねーよ。

テストのフリした違うものを使って開発する方法。
作ったテストもどきはテストとしては使わない。
使い捨てのコード。

やっぱりお前はわかっていない。
2014/02/02(日) 08:56:36.07
> 作ったテストもどきはテストとしては使わない。
> 使い捨てのコード。

は？
2014/02/02(日) 13:36:26.27
>>303
じゃぁお前は、また、お前の会社はどうやってテストだけでなく、開発をしてるんだ？
開発のプロセスを聞いてみたい
2014/02/02(日) 17:35:46.13
>>304,305
俺は303じゃないけど
たぶんお前らはTDDを理解してない
もしくは一部を見て言ってる
2014/02/02(日) 18:00:48.70
ああ、こりゃ「じゃあTDDって何だよ」って問うてもまともに答えられない展開ですわ
2014/02/02(日) 18:54:00.78
【TDD】テスト駆動開発【TestFirst】
2014/02/02(日) 19:03:43.35
TDDの良い所は、コーディングがキチっとなることだと思う
テストがどうとかじゃなく、ブレがないというか

DBがどうとか言うけど、スタブ、モックオブジェクト、なんやらあるだろ
2014/02/02(日) 20:02:31.60
俺こそがTDDの神祖
おまいらは邪教徒じゃ
2014/02/02(日) 20:48:15.81
BDDって使ったことないけど、どう違うの？
TestMethod()とかがUnittestだけど、
BDDの場合はshouldBeEmpty()とかになるんだろ?
2014/02/03(月) 14:30:29.47
>>307
> 「じゃあTDDって何だよ」って問うてもまともに答えられない

その質問は、ググればすぐにわかるから誰も答えないんじゃないの？
ちなみに、Googleの第一位はWikipediaですごくまとまってる。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA
2014/02/03(月) 14:33:11.18
>>304,305
>>303の文章は酷いが、Wikipediaを読めば理解できると思う。

> テスト駆動開発で用いられるテストは、品質のためのテストではない。コード本体とは独立に
> あらゆるケースを網羅するような、テスト自体で価値を持つようなものは目指していない。
> コード本体を合わせて検討することで、開発者が、その正しさに確信を得るものである。
> 開発者の確信に少しも寄与しないテスト（かつ、ドキュメントとしてテストの読者に何かを
> 伝えるために書かれたものではないもの）は、むしろ積極的に削除を検討する。
2014/02/03(月) 17:06:00.43
俺は、TDDで作ったテストメソッドの大部分は、「品質のためのテスト」でも使えるよう修正してくよ。
2014/02/03(月) 18:38:14.74
>>313
そういうことだよな。

393 名前：デフォルトの名無しさん[sage] 投稿日：2014/02/02(日) 08:52:46.17
TDDでコーディングより先に書くテストっていうのは
ちゃんとしたテストじゃないんだ。
本番用のテストとして使えるものもあるが、使い捨てのテストも多い。
だから本番用のテストは別にちゃんと書かないといけない。

つまりこういうことなんだ。

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」
2014/02/03(月) 19:40:04.51
これよかったよ。
http://japan.renesas.com/company_info/lsi_design/
2014/02/05(水) 08:51:07.35
テストをTDDで開発してるのか
2014/02/05(水) 18:24:02.84
t_wadaさんによるスライド
「TDD のこころ @ OSH2014」
http://www.slideshare.net/t_wada/osh2014-sprit-of-tdd

『テスト駆動開発入門』も
『リファクタリング』も
『達人プログラマー』も
絶版になってたなんて……。
2014/02/07(金) 16:30:20.46
>>318
「達人プログラマー」ってなんか東亜プランの中の人かとｵﾓﾀ
2014/02/07(金) 21:50:41.56
TDDの最大のメリットはテストしやすいソースになる事
2014/02/08(土) 13:05:21.69
昔社内の文書でテスト騒動って書いている奴がいて笑った
そりゃ、テストで騒動が起きるのは困るよね
2014/02/08(土) 13:09:53.56
テストで騒動とかプロジェクト毎に起きてるぜ
2014/02/08(土) 17:19:52.71
>>321を素で駆動と読んでｲﾐﾌだったが>>322で読み直してすっきりさっぱりだよ。
2014/02/09(日) 23:04:23.44
まぁ、バグが発生するのはテスト中だからな
2014/02/12(水) 03:55:25.26
完成してなくてもいいから、コンパイルの通らないコードをリポジトリに登録するな、
でないと全体のコンパイルに支障が出る、というのと似たような感じで、
テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
他のモジュールの開発に支障が出るから、ってことかね。
2014/02/12(水) 11:29:02.29
>>325
> テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
これは別にTDDに限った話じゃないだろ
2014/02/12(水) 13:59:27.22
テストを“いちばん重要な財産”と考えると見えるもの
http://gihyo.jp/dev/serial/01/tdd_supremacy
タイトルと概要しか見てないけど、短かい文章でテストの重要性を言い表わしてるなと思ったんでコピっとく
2014/02/12(水) 14:39:26.47
>>327
コードのインデントやレイアウトがキモ過ぎるし、newしたオブジェクトを=&で代入したり、
もう全く信用できないので、本文も読む価値無いね。
2014/02/12(水) 15:34:30.78
>>328
いい加減、ちゃんと問題点を指摘できるようになろうぜｗ
2014/02/12(水) 15:38:44.80
>>329
・コードのインデントがキモイ => 最近のコーディング標準知らないんじゃないの
・レイアウトがキモイ => 最近のコーディング標準知らないんじゃないの？静的解析したことないんじゃないの？
・newしたオブジェクトを=&で代入したり => お前いつの時代のPHPerだよ
2014/02/12(水) 15:41:04.76
>>330
いや、そんなことどうでもいいからｗ
インデントの幅がどうとか言ってるだけじゃん。
2014/02/12(水) 16:00:01.69
>>331
PHPのことあまり知らないんだろうけど、最近はPSR-1/PSR-2/Zend/PEARのコーディング規約に
沿って書くのが普通。
まぁそれを知らないド素人でも、人のコードを見慣れてればあんな酷いコードは書かないだろう。

それに、今時varとかfunction &hoge()とか$fuga =& new Fuga()とかありえないから。

第2回もちょろっと見たけど、あり得ない酷いコードだわ。
2014/02/12(水) 16:04:05.29
>>332
本文読んでないからわかってないんだろう？

> 前回，「これまでの記事で取り上げたコードを，テスト駆動ベースに移行していく」と書きました

これは「これまでの記事で取り上げたコード」だ
昔のコードだって書いてあるだろ。
2014/02/12(水) 16:21:46.58
>>333
へー、第1回と第2回に載ってるコード全てが昔のコードだって言うの？
いくらなんでも古すぎだわ。
2014/02/12(水) 16:32:05.04
PHP のことあまり知らないから他の言語の利用者にもわかるように
説明してくれると嬉しいところなんだけどな
コードレイアウトは技評の Web 記事編集が手を入れないのが悪い
2014/02/12(水) 16:47:05.39
ここにたれ込めばいいと思うよ
http://gihyo.jp/dev/serial/01/php-programming-examination-room
2014/02/12(水) 20:31:31.24
> プログラミングにおいていちばん重要な財産はテストであり，
> 万一コードをすべて失ってしまったとしても，
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
> －この考えを立証すべく，テストとコードの関係を考えます。

この時点で、オレオレテスト駆動
別の名前付ければいいのに
2014/02/13(木) 00:48:59.46
>>337
> プログラミングにおいていちばん重要な財産はテストであり，
これは嘘ｗ
あたりまえだけどテストよりも動くコードの方が重要。

テストコードはあっても今すぐには価値を生み出さない。
今すぐアプリとしては動かないのだから。価値を生み出すのはアプリのコードの方。
テストコードはなくても動くが、アプリのコードはなかったら動かない。

アプリコードからテストコードを生み出すことはできるが、
テストコードがあってもアプリコードは生み出せない。
仮にテストコードからアプリコードを作り出すことが可能だとして
それにかかる時間はどれくらいかかるか。その間テストコードに価値はない。

そしてテストコードからアプリコードを書くのは不可能
なぜなら全てのコードをテストしているわけじゃないから
その主な例がユーザーインターフェースデザイン、
分かりやすく言えばHTMLで作られた入力画面等。
テストコードがあっても使いやすい（同じ品質の）入力画面は復活不可能。

また現実的な問題としてテストコードが全て書かれているという証明はできない。
アプリコードがあるなら当然そこにすべての動作が記述されているが
テストコードは全てあるとは限らない。

あたりまえだけどアプリのコードのほうが重要。
2014/02/13(木) 01:16:10.11
>>338
アプリコードの方が重要って考えは視点が違うだけだからなんとも

そもそもTDDスレとしての突っ込みどころはオレオレテスト駆動であって
そんなアプリコードとテストコードどっちが重要かってところに
そこまでの長文を書いてまで反応する意味が分からない
2014/02/13(木) 02:24:17.12
>>339
反応する意味がわからない？
ただ書いただけだろ？
何か問題が？

それを言ったら、お前がレスする意味がわからない ← どう答える？
2014/02/13(木) 09:57:16.39
プロレスで相手の手の内を出させないままキックだけで勝って俺TUEEEみたいな
2014/02/13(木) 11:04:59.49
おまえら勘違いすんな
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
同じ*品質*のコードといってるんだ
テストが保証するのはコードの品質であってアプリの価値ではない
ましてや同じ入力画面を復活させる事では全くない
2014/02/13(木) 11:22:44.29
ゴミページを擁護してる奴は何が目的なんだ
2014/02/13(木) 13:59:44.58
TDDどうこうよりも、テスト対象のクラスを継承したテストクラスを作って、テスト結果の確認をテスト対象クラスのメンバに設定された値でアサートするというやり方がセンスないわ。
2014/02/13(木) 20:48:44.35
アプリのソースだけ残った場合と
テストコードだけが残った場合

どっちが安価に元の状況に戻せるの？
2014/02/13(木) 20:55:48.07
>>345
リファクタリングしまくる人の場合は、残ったソースをいずれ破棄したり書き直したりしてしまうので、
テストコードだけ残った方が安価なときもある。

TDDはそういう人向けの手法でしょ。
2014/02/13(木) 22:49:05.90
TDDはアプリのソースとかテストコードがどっちが残ると～とかそういうことを
語るもんではないんだが
2014/02/14(金) 01:07:04.09
おおよそ、テストをどうやって書くかを考えるのが設計になり、
テストをどのように満たすかを考えるのが実装になる。

テストとコードを共に成長させていって開発を進めるのだから、
片方だけ残して、これがテスト駆動開発だ！とか言われると
ゲフンゲフンとなる。

品質との関連性は微妙
2014/02/14(金) 02:07:53.24
＞テストとコードを共に成長させていって開発を進めるのだから、
成長が順調に進むのであればテストファーストもコードファーストも大差なく
テストとコードのどちらを先に書くかの順番の違いしかないが、

成長が逆戻りした（コードに修正を加える必要が出てきた）ときに
テストを優先して（テストの中に設計を含めて）コードを大胆に修正できるようにするか、
コードを優先して（コードの中の設計を維持するように）コードの修正量をなるべく少なくするか、

という所に違いがある、という感じか。
2014/02/14(金) 02:10:51.12
＞品質との関連性は微妙
実装フェーズが完了した段階ではコードもテストも固まっているから
テストファーストでもコードファーストでも同等の成果物が作成されて
同等の品質が得られているはず、ということなんだろうか、

それとも、実装フェーズではそれなりに動くモノができていればいい、
品質はその後の試験フェーズで高めていく、という考え方なんだろうか。
2014/02/14(金) 10:08:16.40
>>348
> テストとコードを共に成長させていって開発を進めるのだから、
> 片方だけ残して、これがテスト駆動開発だ！とか言われると
> ゲフンゲフンとなる。

誰も本当に片方捨てろなんて言ってない

> テストが無事なら元と同じ品質のコードをもう一度書くことができる。－この考えを立証すべく

って考え方を言ってるんだよ
お前は抽象的な話しが出来ない奴か？
2014/02/14(金) 10:51:38.30
>>351
> > テストが無事なら元と同じ品質のコードをもう一度書くことができる。－この考えを立証すべく
>
> って考え方を言ってるんだよ
> お前は抽象的な話しが出来ない奴か？

これのどこが抽象的な話なんだ？

「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
で、論破。
2014/02/14(金) 11:11:56.77
後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されている
テスト一式があれば、元コードと同等のものを翔かもしれないが、このこととTDDは
一切関係無いね。
2014/02/14(金) 11:31:08.45
>>352
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> で、論破。

論破って…単なる仮説を立てただけだろ。立証してから言ってくれ
そういう分かりやすい最終的な結論だけで話しを進めるたがる事を
抽象的な話しが出来ないっていうんだよ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況