テストツールについて語るスレ

このエントリーをはてなブックマークに追加
950デフォルトの名無しさん:2007/07/21(土) 22:45:45
フロントエンドが何を指すのか、コンパイラっぽいっことことってなにを
言ってるのかよくわからんけど、構文解析あたりまではやらないと解析で
きないだろうし、PG-Relief あたりだと簡単なフロー解析ぐらいはやって
るんじゃないかな。
951デフォルトの名無しさん:2007/07/21(土) 23:11:16
FindBugsとかその系統の話か?
大雑把に構文解析と同時に悪いイデオムとのマッチングをしているね
気になるならばソース読むのが一番だが
952デフォルトの名無しさん:2007/08/06(月) 22:48:12
誰もいないry

privateのテストなんて
テストのプリプロセス時に
publicへしてしまえ。
953デフォルトの名無しさん:2007/08/09(木) 03:28:37
privateのテストなんて
外部からテストする意味がわからんw
954デフォルトの名無しさん:2007/08/09(木) 18:23:51
ファインド虫ズはバイトコード解析じゃね?
955デフォルトの名無しさん:2007/08/22(水) 23:44:59
232
956デフォルトの名無しさん:2007/12/11(火) 10:46:59
あのさ、テスト用のフレームワークは使わずに、
各クラスにテスト用の静的メンバ
static bool MyClass::Test(); を用意して、
とりあえず main 関数の先頭で assert(MyClass::Test());
ってチェックができるようにしてるんだけど、
たまに Test() の呼び出しを忘れるんだ。

プログラム中で使ってるクラスは50ほどあるんだけど、
なんとか忘れずにすべてのクラスの Test() を
呼び出すように強制する方法ってないかな?
957デフォルトの名無しさん:2007/12/11(火) 11:56:29
>>956
それ、何時間かけて解決するつもり?
958デフォルトの名無しさん:2007/12/11(火) 23:29:43
強制するうまい方法は思いつかないけど、すべて呼ばれているかどうかをチェックするだけなら簡単じゃないかな。

$ grep 'assert¥(.*Test¥); *.java | wc -l # 呼び出している行の数
$ grep 'static bool .*::Test¥(¥)' *.java | wc -l # 定義している行の数
これが等しいかどうかをチェックする。
959  :2008/01/10(木) 23:37:55
 
960デフォルトの名無しさん:2008/01/11(金) 04:27:47
リフレクション使って、あるパッケージ内の全てのクラスについて
static bool Test() があればそれを呼ぶってコードを書けばいいんじゃない。
961デフォルトの名無しさん:2008/01/11(金) 10:46:35
>>956
phpやrubyならglob使って特定のディレクトリにあってファイル名にTestがついてるの
全部requireとかでいける。
Cとかなら自分でスクリプト書いて、テストスィート自動生成。
962デフォルトの名無しさん:2008/02/09(土) 10:36:48
TestDriven.NETをアップデート(ver.2.12)したら
ウンともスンともいわなくなっちゃいました。
(テスト時のビルドすら、し始めてくれない)

しょうがないので、今までのバージョンに戻してみると(2.7)
普通に動いてくれます。

ググってみても、同様現象に関しての記事はを見あたらないのですが
同じような方、または解決法など ご存じの方がいらしたら お教えください。

ちなみに 環境は Vista、VC#2005EE です。
963デフォルトの名無しさん:2008/03/29(土) 03:13:51
>>962
テスト駆動開発なんて、アテにならないという証だなw

テスト駆動開発って、ホントに糞糞レベルの品質は避ける事が出来る、というだけで、
よい品質のソフトを作れる方法論じゃないよな。

まともな現場なら、モジュールとして動き始める頃には、
純粋なコーディングミスなんてほとんど出なくなって、
インタフェース誤解とか仕様自体のミスとかだけ。

テストコードなんて、現実には王道パターンひとつかふたつと、
「テストしやすい」妙なパターンいくつか、程度。まともな現場で起きる現実のバグは、
テスト対象オブジェクトが持つオブジェクトが持つオブジェクトが妙なパターンとか、
とてもテストコードなんて書いてらんないようなのが条件。

モジュールとして動き始めると純粋なコーディングミスがダバダバでるような、
「動きました出来ました」レベルの現場なら、品質は大きく向上するけど、それだけ。
964デフォルトの名無しさん:2008/03/29(土) 03:58:52
レス乞食乙
965デフォルトの名無しさん:2008/03/29(土) 06:07:13
業務システムなんて、ぶっちゃけバグの山だからな。
そのシステムで動いてる分には発生条件が起きないってだけの不発弾が大量に眠ってる。

稼働済みシステムのうちの、フレームワーク(として使える)部分を抜き出して、
他のシステムに適用したら、新たなバグが出るわ出るわ。元のシステムは安定してるのに。

出ないバグはバグじゃない。業務システムのソース品質なんて中品質でいいんだよ。
966デフォルトの名無しさん:2008/03/29(土) 16:34:00
>>963
テスト駆動開発をまったく理解してないいい例。

> テストコードなんて、現実には王道パターンひとつかふたつと、
> 「テストしやすい」妙なパターンいくつか、程度。

単に、君の能力がそこまでと言うこと。(w
967デフォルトの名無しさん:2008/04/09(水) 21:05:11
Nunitでテスト結果の詳細を出力する方法はないのでしょうか?
(成功・失敗にかかわらず、Assertごとにメッセージを出力など。)


そのまま単体テスト結果表にしたいので。。。
968デフォルトの名無しさん:2008/04/10(木) 12:31:24
>>966
>>963がTDDの理解どう足りないのか、
どういうやり方なら>>963のいうレベル以上がTDDで実現出来るのか?
それがなければ、反論になってない。
969デフォルトの名無しさん
>>968
で、君はTDDの本読んだことあんの?