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

1 ：08/04/13 ～最終レス：11/11/25: プログラムにテストはつきもの
xUnit の効率的なテストコードの書き方やその他テストツールに
ついて語りましょう。
テストツールについて語るスレ
ttp://pc11.2ch.net/test/read.cgi/tech/1030721755/

2 ：: 悪いが、これからは、xUnitではなくBDDの時代。
　　　　　　　　　　　　　　完
3 ：: 前スレ >>996-997
TDD は、テストコードを書くことによって仕様が明確になることを
期待してるから、実装の前にテストコードを書くことを薦めている。
要するに、テストコードは仕様書をよりブレークダウンしたものと
考えればいい。
もちろん全ての仕様がテストコードにできるわけじゃないけど、
多くのあいまいな仕様はテストコードを作成する時点で、あいまい
と言うことがわかるから明確にできると言う効果がある。
プログラムを作成する時点でも同様にあいまいな部分はわかるけど、
一般にプログラムの作成はテストコードの作成より時間がかかるか
ら、プログラムを作成した時点で仕様が明確になっても対応できな
いケースがほとんど。(これが今までの流れでしょ？)
その上に、適切なツールを併用すれば作成したテストコードを用い
て自動でテストができる。実用的にはこっちのメリットも大きいけ
ど、手法としてはどっちかって言うと副次的な効果なんだな。
>>2
手法とツールの区別もついてない奴はこのスレには不要だから、
もうこないでね。
4 ：: 悪いが、これからは、TDDではなくxSpecの時代。
　　　　　　　　　　　　　　完
5 ：: >ちょっと実装→すぐテスト→ちょっと拡張→またすぐテスト
その最初の「ちょっと」が本当に「ちょっと」なら問題ない
あと、「ちょっと拡張」後のテストで前のテストに失敗していないことを確認できるならおｋ
6 ：: 「テスト駆動“開発”」（TDD）というプラクティスを掲げていますが、実質的にはむしろ「テスト駆動“設計”」なんです。
むしろ、設計をコード・ベースでやったらテストになった、という方が適切だと思います。
7 ：: >一般にプログラムの作成はテストコードの作成より時間がかかるから、
一般にと言えるほど明確ではない
8 ：: >>5
「ちょっと」の大きさはプログラマのスキル。
TDDでも「一歩」の大きさは本人の自信に依存すると言っているだろ？
9 ：: 現実にTDDが役に立ってるって人がいるのに、いや、お前は勘違いしてる、
実は役に立ってないんだって説得したいの？
10 ：: 開発手法レベルの話で○○は役に立つ、立たないというのは
そもそも一開発者が判断できることじゃないけどな。
TDDをどれだけのプロジェクトに適用した経験があって
開発要因のスキルのばらつきの中で導入コストがどうで
TDDと従来法の比較でそれぞれバグ発生件数の推移がどうで
それが結果的に開発工数をどのように削減していて
とか真面目にやらんと判断なんかできない
2chのこういう場所で役に立つ立たないというのはどちらも
好き嫌い、俺の性格に合ってる俺には合ってないレベルの感想だな
それが悪いとは言わんしそれ以上を期待するのが間違ってるんだけどな
11 ：: 開発手法レベルで、役に立つ・立たないを合意できないと、使うこともできないの？
12 ：: >>10
何かを真面目にやれば、「品質」が測定できるとでも？
工数は測定できるがな。
13 ：: >>12
現実にソフトウェアメトリクスが役に立ってるって人もいるのに、
いや、お前は勘違いしてる、
実は品質なんか測定できないんだって説得したいの？
14 ：: TDDを使うことによって変化する（した）品質を測定できるのかって聞いてるんだが。
測定できるとでも？
15 ：: >>14
測定すらできないものの役に立つ立たないを議論できるとでも？
16 ：: 測定なんかしなくていいという立場だが。
17 ：: ウケル、頼むから釣りと言ってくれ
てか自宅で数十万単位の小銭稼ぎを繰り返すフリーか？
18 ：: >>17
>>11
19 ：: >>10
TDDは普通xUnitとあわせてやるもので、TDDのメリットがどれくらいかを測定するためには、
xUnitを使いなれた環境でなおかつTDDを採用していないチームで測定する必要があり、
それは現実的じゃないと思う。
俺もKent BeckのTDD本は読んだが、教条的なTDDには現実味があまり無いと思った。
もともとスキルがある程度ないと実行できないだろうしね。
TDDはガイブインターフェース決定後の実相開始以降の手法だと理解したが、そこでメリットが
あると感じた個人が採用すればいいんじゃないかと思った。
20 ：: typoしまくりすまん。
21 ：: >>10
品質測定の可否はともかく、そう言う話は2ch向きじゃないな。とても、文字のみ2048文字では足りない。
話を変えるけど、TDDって難しくね？
馴染んだ奴らには自然のことなんだけど、
例えば一山いくらの人足プログラマにできるかというと、無理だと思う。
何故かって、TDDは設計もしないといけないから。
単に設計するだけじゃなくて、業務要件をこなしつつテストしやすいような設計を、
コード書きながらしないといけない。
言われたとおりコード書くだけの三下プログラマには難しすぎる。
じゃあ、必要なスキルを持ったエンジニアを、工数と期間を踏まえた分だけ
そろえられるかというと、規模によっては無理だろうな。そしたらTDDの導入は困難だ。
前スレでTDD導入の可否は開発手法の影響を受ける、という主張があったけど、
それは結果論で、優秀なエンジニアをそろえられないから
少数の仕様設計者＋下っ端大勢の体勢が不可欠になり、結果としてTDDが導入できない、
って事だと思う。
後は、人数が増えすぎると、設計を個々のエンジニア任せにした時に
意思疎通が難しくなって、てんでばらばらな設計になるって問題も考えられる。
AはAの流儀でTDDで設計&実装し、BはBの流儀でTDDする。
AとBの意思疎通が取れていれば、AとBの書くコードの差異は小さいけど、
人数が多いと意思疎通が難しくなる。
そこで意思疎通を怠ると、Aの設計とコードにBは違和感を覚え、直したくなる衝動になられるだろう。
エンジニアはこういう所にうるさい奴が多いから、後戻りになるかチーム内で不和が生まれるかするかもね。
22 ：: >>19
自分の印象もそんな感じだな
仕変要求がメールや口頭で飛んで「じゃ、あと、よろしく」な仕事だと
開発のスピード感を維持するためには必然的にTDDにならない？
>>21
これも同意
言い換えれば、エンジニアが強い（＝仕様設計レベルに口を挟める、
お客さんと直接対話できる）立場に置かれていないとTDDは難しいと思う
その意味でケントベックの本ってある意味ストレスがたまらない？
前半くどくど書いてある内容は一定レベルのエンジニアなら紙ぺら３，４枚で済む内容で
本当に知りたいのは最後の方のQ&A集みたいな章、たとえば
「巨大システムをテスト駆動することができるのか」みたいなとこだったり
するんだけど、そっちはあの本では満足のいく答えが全く得られない
23 ：: >>7
お前さんのところのプロジェクトでは設計工程よりチェックリスト成に時間を
割いてるの？
もしそうなら、それはすばらしいことなので、TDD なんか無視してこれからも
がんばってください。
>>21
色々書いてるけど、結局アホには無理ってこと？
それは、別に TDD に限った話じゃないと思うが。
でも、普通のやり方だとタチの悪いアホが発覚するのはテスト工程に入ってか
らだけど、TDD やってれば製造工程の速い段階で露見する可能性が高いから、
やる意味はあると思う。
>>22
> 「巨大システムをテスト駆動することができるのか」みたいなとこだったり
激しく TDD を勘違いしてない？
24 ：: >>23
>> 「巨大システムをテスト駆動することができるのか」みたいなとこだったり
>
>激しく TDD を勘違いしてない？
kent beckがか？ｗ
25 ：: ??? 勘違い君、乙なのかな...
26 ：: 語る前に本くらいは
27 ：: xUnitを使ってるがＴＤＤはしてないとこなんていくらでもあるだろ。
それをそんな奴はほとんど居ないなんて思っちゃう視野の狭さが、信者なんだろうな。
28 ：: >>22
> >>19
> 自分の印象もそんな感じだな
> 仕変要求がメールや口頭で飛んで「じゃ、あと、よろしく」な仕事だと
> 開発のスピード感を維持するためには必然的にTDDにならない？
んー、ならない（笑）
red-green-refactoringは、まどろっこすぎて俺には合わない。
> >>21
> これも同意
> 言い換えれば、エンジニアが強い（＝仕様設計レベルに口を挟める、
> お客さんと直接対話できる）立場に置かれていないとTDDは難しいと思う
俺は19に書いたように、TDDって外部設計が終了し、内部設計で言う所の外部インターフェースが
決定し、各タスク（モジュール）が各人にアサインされた後の開発手法だと理解してるから、
要件定義とは関係ないと思ってる。
TDDをうまく使いこなせて、快適だと感じれば使えばいいんじゃない？って感じ。
29 ：: >>27
そう思ってる奴はお前の脳内にしかいない。

30 ：: >>28
なるほど。同じTDDでも使い方が違うね。
俺は逆に外部インタフェースがしっかり確定した状態で渡されるなら
あとはコードに落とすだけだから、そういうカッチリした仕事だと
むしろレッド、グリーン、がまどろっこしく感じる。
そういう仕事の場合はシンプルに実装、グリーン、ＯＫ。
31 ：: おい、外部仕様って言ったら、ユースケースと画面とワークフロー程度だろ。
32 ：: 頑固な派遣テスターはテストツールなんて使いません
http://pc11.2ch.net/test/read.cgi/prog/1207581904/
ただただテキトーにプログラムを触る、それがホントウのテスターなんです！
33 ：: >>30
なんか、「外部インターフェース」について、俺と大きなズレがあるけど、まーいいか。
34 ：: まぁ実際は公開インタフェース含めてリファクタリングの対象となるわけだが、
実装内部の構造について事前に決定せず、
(最初にレッドにするかはともかく)レッド→グリーン→リファクタリング
で確定させるYO!
35 ：: 外部インターフェースって、公開I/Fとか入出力情報とかプロトコルとかだろ。
これが決定した後で「あとはコードに落とすだけ」なんてありえん。
36 ：: >>30の言うことを解釈すると、外部インターフェースが確定していない状態なら、
レッド、グリーンがまどろっこしく感じないと読めるが、全く意味がわからん。
どういうこと？
37 ：: >>30
> 俺は逆に外部インタフェースがしっかり確定した状態で渡されるなら
> あとはコードに落とすだけだから、
要するに、コーダー君と言うことかな？
38 ：: 158 ：仕様書無しさん：2008/04/13(日) 00:40:17
このコードいじり悩み悩み悩み続けた
既に書いてあるはず？もマジで見当たらない
繰り返すと過去にできていた機能が消えた
このすごい　バグが最後で最後最後か？
寝させろ・「わーっ！！」　マシンが古くて砕けた
そりゃも体調は落ちる　僕の胃にピロリがw
39 ：: Seleniumの話題はここでおk？
40 ：: テスターはツール扱い？
41 ：: 反復的にこき使われるという点ではyes
42 ：: 工期圧縮で真っ先に短縮されるのがテスト工程。
客からのクレームで真っ先に責め立てられるのがテスト工程。
やってらんねーよ！
43 ：: テストしてない工程表を作ればいいんじゃね？
入力チェック・・・工期圧縮で省略
トランザクションチェック・・・工期圧縮で省略
44 ：: Test
45 ：: 自分からテスト専門です、って宣言してる派遣テスターって何なの？
将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。
俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。
今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？
あ～あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ～、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。
派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！
46 ：: 板違い
47 ：: >>45
このスレ的にはそういうバカテスターの問題も避けて通れないよな
そういうヤツが一人ういるとテストツールの普及が妨害されるからね
48 ：: >>45
派遣同士底辺で仲良くしてなよ。
>>47
そう言う話題はマ板でやってくれ。
49 ：: 過疎スレなんだから目くじらたてんなよ
50 ：: >>45はコピペ
51 ：: コソコソ告げ口
契約切られて逆恨み、愚痴をリピート
それが底辺派遣テスター
52 ：: GUI部分の効果的なテストツールってない？
みんなどうやって品質上げてるの？
実装とテストの大半が画面周りに費やしちゃってハゲそうれす
53 ：: >>52
HTMLならあるよ。
54 ：: GUIイベントの記録と疑似再生のツールぐらい、普通につくってないか？
55 ：: 俺もこの前まで派遣テスターやってたけど、派遣テスターって渡されたテストをやるだけじゃないの？
10年以上続いてる大きいプロジェクトだからか、全体図もよく分からず仕様書なんかも「見たければ見てもいいよ」くらいの感じで、
自分で仕様書作るなんてありえなかったんだけど
56 ：: そりゃ派遣テスターって言っても形式的にはテスト実施だけのケースから
テスト全体計画立案まで含むケースまであるだろ。
まあ、テスト全体計画立案まで派遣に任せるようなところは開発からほと
んど丸投げ状態だと思うが。
57 ：: 立案書じゃなく仕様書の話だろ
58 ：: 立案書？なんだそれ。
59 ：: テスト全体計画立案

60 ：: いや、別に立案書とか言う名前のドキュメントがあってもいいんだが、
あまり聞いたことないから聞き直しただけだよ。
ちなみにうちでは、テスト全体計画立案の内容を書くのはテスト計画書
という名前のドキュメント。
61 ：: 55の仕様書を56がテスト計画立案と勘違いしてる
62 ：: >>56 は、>>55 の
> 俺もこの前まで派遣テスターやってたけど、派遣テスターって渡された
> テストをやるだけじゃないの？
についてのレスだよ。
そもそも >>55 に書いてある「仕様書」は、テスト仕様書なのか設計仕様
書なのかもはっきりしないからあえて無視した。
で、その話と「立案書」ってなんか関係あるのか？
63 ：: 「見たければ見てもいいよ」な仕様書なんてあるのか？
64 ：: >>63
「誰も見てないよ」な仕様書ならある
65 ：: 最近ratproxyとか使い始めて思ったんだけど、これってサイトの脆弱性を見つけて攻撃してやろうとしている攻撃者にとっても有用なツールだよね。
サイト巡回してるだけでどこに脆弱性あるか分かるんだから。
こういう悪意の攻撃者にヒント与えるのを簡単にしていることってあんま問題になったりはしないんですかね？？
66 ：: >>65
開発者・設計者も使えるんだぜ？
67 ：: >>65
むしろ公開されていることに感謝かな。
悪意のある人はそういうツールを作って自分だけで使うだろうから。
68 ：: すみません
テスト駆動開発って普通に使ってるんですか？
自分、最近JUnit使ってテスト駆動開発やれと言われたのですが、あまりのめんどくささに死にそうです
たとえば、単なるDTOに関しても、テストするように言われてますが、フィールドが3個、getterが3個、コンストラクタは1個(引数はフィールドに代入する3個)のDTOテストするにも一苦労です
publicなメソッドを全てテストせよと言われてるのですが、getterごとにテストするたびに似たようなテストコード書き、そのたびにコンストラクタを少しずつ変えていくなどテスト駆動開発を忠実に守ると死にそうです
これ、みなさん普通にやってるんですか？
もう、会社辞めたい
69 ：: そんなレベルのテストだったら30秒で書けるだろ
70 ：: >>68
DTOくらい、IDEなりXDocletなりで自動生成するだろ。
そんな、ツールが自動生成するコードはテストしない。
ツールのバグを疑うなら、ツールのテストケースを使って検証すべきであり、
ツールの出力すべてをテストする必要はない。
お前は一体何をテストさせているつもりなのかと、上司に聞いてみろ。（聞けたらね）
71 ：: そんなくだらんことで思い悩んだりバトルするより、public methodのカバレッジ100%のテストをさくっと作れよ
72 ：: レスありがとうございます
>>69
失敗するテストを書く、テストをパスするコードを書く、リファクタリングをするを真面目にやると30秒では無理じゃないですか？
たとえば、getA、getB、getCの3個のテストを考えると
最初にgetAのテストを書く→Aを引数にとるコンストラクタを作る→getA実装→三角測量でパスするまで続ける
次にgetBのテストを書く→Aを引数にとるコンストラクタをA、Bを引数に取るコンストラクタに変更→getAのテストに修正の必要発生→グダグダの上すごい作業量になる
とかなりませんか？
>>70
そういう考え方もありますね
DTOは確かに自動生成すべきでしょうね
上の例でDTOを上げたのは、一番最初に思いついた例だからです
ちなみに、自分はテスト自体は必要だし、JUnitも有効なツールと考えています
しかし、テスト駆動開発はあまりにも無駄な作業が多いのでは？と疑問に思ってます
各クラスの使用をしっかり決めて、危険そうな箇所だけテストケース書くとかじゃだめなのかな？
テストが仕様書だと言ってもプログラマ以外は認めてくれないと思いますし
>>71
疑問なのですが、カバレッジ100%のテストはさくっと作れますかね？
カバレッジ100%の意味がどの程度なのかわからないのですが、
例外処理とか入れたら細かいクラスでもそれなりの作業量になるし、
ましてや複数のクラスを統括するクラスは凄まじいテストパターンが必要な上、
細かいクラスで行ったテストとほぼ同じ作業になりそうですし
73 ：: コードの網羅率のカバレッジじゃなくて、methodの網羅率100%のテストってこと。
それが求められてるんだろ？
それと、テストが必要かどうかが既にわかってるのは、元コードを書いた人間だけ。
外部の人間がメトリクスを取るとき、いちいち元コードの内容を見て、テストが無い
ことの妥当性を確認するのは手間だろ。だからさくっと作れって。
74 ：: つか、悩んでるならTDD本まず読めって
75 ：: >たとえば、getA、getB、getCの3個のテストを考えると
>最初にgetAのテストを書く→Aを引数にとるコンストラクタを作る→getA実装→三角測量でパスするまで続ける
>次にgetBのテストを書く→Aを引数にとるコンストラクタをA、Bを引数に取るコンストラクタに変更→getAのテストに修正の必要発生→グダグダの上すごい作業量になる
これがまず間違ってる。
あるオブジェクトがオブジェクト足りうるのに必要な情報が三つあるなら、その三つを引数に取る
コンストラクタのテスト・実装から始める。
それがパスし、なおかつ外部I/Fが必要なら、getterのテストを追加する。
さらに、コードが明白なら、三角推量なんかしないでよい。
76 ：: >>73
さくっと作れの意味がよくわからないのですが、必要なテストを自分で考え実装しテストするという考えだと、テスト「駆動」開発にならないきがするのですが
>>74
本とwebで情報収集はしました
その結果、真面目にテスト駆動開発する意味がわからず悩んでます
>>75
コンストラクタのテストとは具体的に何をやるのでしょうか？
リフレクション使ってprivateなフィールドの状態確認するのですか？
解説者により内容が違うのですが、基本的にテスト駆動開発ではpublicなメソッドに対しテストを行い、内部状態などを見るのは別のテストという記述を見たので、それにしたがってます
77 ：: TDDの目的は品質を保証することだ。テストコードを書くのが目的じゃない。
目的と手段をごっちゃにしちゃダメだよ。
78 ：: 今の現場　Nunit　とか言う糞面倒臭いツールを使っていてそれを
必ず通さないと駄目！！って事になってる。
わざわざそのNunitを通す為のプログラムも作成しなくてはならないとか
糞杉。
テストツールって意味あるのか？
マジで無駄に工数がかかってしょうがないと思う。
あと訳の分からん無駄な独自フレームワークを使ってるプロジェクトとかも最悪。
79 ：: うちは、工数がかかって仕方ないから、TDDやめたクチ
リリースしてバグ出てから、バグとった方が圧倒的に効率的。
どうせ、TDDやっても手動テストする時間くらいは別にとるんだしね。
第一、そのバグ修正とかが、必要かどうかってのは運用してみないとわからない。
そんなところをあらかじめ工数かけてつぶす意味がわからない。
品質がよいものを作るのが目的ではなくて、顧客が満足するものを作るのが目的だからね。
結局、TDDやめたら工数的に2倍くらい早くなった
80 ：: >>72
>各クラスの使用をしっかり決めて、危険そうな箇所だけテストケース書くとかじゃだめなのかな？
主観だと断っておくとして、
テスト駆動開発は、テスタビリティと保守性に優れた設計および実装と、
結果として得られる自動テストスイートを、
低コストで安定して得るための方法論であり、
その結果得られる安心と勇気こそが、TDDの価値であると思っている。
そのためのアレンジは認められてしかるべきだと思うし、
逆に、テスト駆動開発の原則に縛られて生産性を損なうようでは本末転倒。
「こんなの自明で、より最適な設計や実装もなければ、バグが入り込む余地もない」と
開発者が皆思うようなところは、TDDはしない。
つまり、1+1=2をTDDしない、ということ。
ただし、注意しなければならないのは、「その設計と実装の正当性はホントに自明か？」ということ。
あなたが当たり前のように実装したコードに、実はバグが潜んでいるかもしれない。
または、今月のあなたが最適と思って設計し実装したコードが、来月のあなたにとってはクソのように思えるかもしれない。
そういう判断は難しい。あなたのいう「危険でない」は、どの程度信用できるのか？
安心して信用できるまでは、TDDのルールを破るべきではない。
ただし、比較的判断しやすいところとして、
>>70で挙げたような自動生成されたコードがある。これはTDDしなくていいだろう。
getter/setterだけでなく、コンストラクタを自動生成できるツールもあるので
それらの機能の利用を薦める。IDEならEclipseとか。
つうか、DTOをネタにするのは、この辺で止めた方がいいね。
まとめると、TDDは安心と勇気を手に入れるための手段なので、
安心と勇気が損なわれない程度にはアレンジしてよし。
ただし勇気と蛮勇の違いに注意せよ。
81 ：: 色々とレスありがとうございます
自分なりに考えて部署の人に話してみます(非公式な立場で)
82 ：: >>76
>コンストラクタのテストとは具体的に何をやるのでしょうか？
インスタンス化してエラーが発生しないことを確認するコード。
>リフレクション使ってprivateなフィールドの状態確認するのですか？
しない。Moneyクラスの例読んだんだろ？
>解説者により内容が違うのですが、基本的にテスト駆動開発ではpublicなメソッドに対しテストを行い、内部状態などを見るのは別のテストという記述を見たので、それにしたがってます
違う。publicメソッドに対してテストを行うのではなく、要求にしたがってテストを書く。
その要求を実現するためには、publicメソッドが必要なんだよ。
>さくっと作れの意味がよくわからないのですが、
だから、publicメソッドを100%カバーするテストが要求されてるんだから、そのことに対してあれこれ上司と
バトルして時間使うより、さくっと作れって言ってるんだけど、意味わかんない？
>必要なテストを自分で考え実装しテストするという考えだと、テスト「駆動」開発にならないきがするのですが
本読んだんだろ？
気のせいだ。
83 ：: ひょっとして「さくっと」の意味がわからないのか？
さっさと作れってことだ。
84 ：: >>80
管理する側の観点から見ると、プログラマの資質もコードの質もテストコードの質もわからないんだから
（もちろんコード見りゃわかるが）、管理上publicメソッドを100%網羅するテストは最低限書いとけってのは
ありだと思う。自動チェックできるしね。
なので、このpublicメソッド100%の話は、TDDの精神とは別に考えるべき項目だと思う。
85 ：: みんなでテストツール作りませんか
86 ：: まずは仕様をageようか
87 ：: http://pc11.2ch.net/test/read.cgi/php/1224838013/327-
327 ：nobodyさん：2009/02/11(水) 01:00:58 ID:???
Railsの簡単なリファクタリング方法教えてくれ
328 ：nobodyさん：2009/02/11(水) 02:58:01 ID:???
ユニークじゃない処理をPickUp
↓
ライブラリorプラグインを探す
｜↓ない
｜最初に戻る
↓ある
置換える
↓
テスト
329 ：nobodyさん：2009/02/11(水) 10:50:42 ID:???
Railsなら最初にテストを記述じゃないの？直すたびに手動でテストはめんどいよ
330 ：nobodyさん：2009/02/11(水) 11:12:12 ID:???
>>329
同意。
標準のTestUnitではなくて、最近はRSpecのほうが流行りなのかね。
あ、でも仕事の場合、テスト仕様書とテスト結果表をエクセルで
書かないと納品物として認めない客が多いので、
Railsのテスト(TestUnit/RSpec)に加えて、手動テストが必要だよね。
331 ：nobodyさん：2009/02/11(水) 11:49:55 ID:???
つまりRSpecの出力フォーマットにエクセル(つーかCSVでいいや)を追加すれば……
332 ：nobodyさん：2009/02/11(水) 11:54:18 ID:???
おー。なるほどね
線引いたり、フォントとかの体裁はVBAでがんばればいけるかな？
88 ：: 333 ：nobodyさん：2009/02/11(水) 12:58:05 ID:???
Rspecっていいのけ？使ったことないのだが。
ttp://jp.rubyist.net/magazine/?0021-Rspec
(略)
335 ：nobodyさん：2009/02/11(水) 13:36:31 ID:???
>>333
自分的にはテストの表示結果が非常に分かりやすいのが気に入ってる。
TestUnitではどのメソッドが成功した、失敗したというのは分かるんだけど、
それぞれが何のテストなのかが分かりにくい。
(略)
337 ：nobodyさん：2009/02/11(水) 14:40:35 ID:???
BDDって何だろ，って思って勉強しながら使ってたら
いつの間にかTest::Unitよりもなんとなくしっくり来て(慣れたからだと思うけど)使ってる
結局概念的にはあんま理解してないと思うけど，TDDの発展形らしいのでとりあえず満足してる
(略)
338 ：nobodyさん：2009/02/11(水) 16:55:40 ID:???
shoulda
(略)
339 ：nobodyさん：2009/02/11(水) 16:57:54 ID:???
SVNにコミットしたら自動で全部テストして
エラーが起きたらメールで通知
rspec＆autotestおいしいです＾q＾
所で宍道湖つかってる人いる？
(略)
89 ：: 342 ：nobodyさん：2009/02/11(水) 20:05:42 ID:???
テストはSeleniumでするものです
(略)
346 ：nobodyさん：2009/02/11(水) 23:28:18 ID:???
Ajax部分は、まぁSeleniumとかの担当になるだろうなぁ。
あと、CIでやるテストと、納品に必要なテストは違うよね。
347 ：nobodyさん：2009/02/11(水) 23:29:01 ID:???
CI=Continuous Integrationね、一応。
349 ：nobodyさん：2009/02/12(木) 02:02:30 ID:???
テストは客のためじゃなくて自分のためにするもんだけどな
350 ：nobodyさん：2009/02/12(木) 02:16:23 ID:???
客に提出するためのテスト資料ってわりといい加減なことが多い気がする
提出したあとにプログラムを変えて、テストは思いっきりおろそかとか
で、客の信頼を失ってテスト資料の提出をせまられる
351 ：nobodyさん：2009/02/12(木) 02:21:07 ID:???
テストを記述＆テスト
↓
ユニークじゃない処理をPickUp
↓
ライブラリorプラグインを探す
｜ある　↓ない
｜　　　ライブラリorプラグインを作る
｜　　　↓作った　　　　　↓作らない
｜　　　テスト記述を追加　最初に戻る
↓　　←こっち
置換える
↓
最初に戻る
352 ：nobodyさん：2009/02/12(木) 02:27:13 ID:???
実際にはあんまみんな自動テストしてないんだろうなと思ってる
どうせ最低限手動テストも必要だしね
このスレに来るような層だとおもしろがってRuby使ってる人が多いだろうし，使ってるだろうけど
90 ：: まずは仕様をageようか
91 ：: >>82
>違う。publicメソッドに対してテストを行うのではなく、要求にしたがってテストを書く。
>その要求を実現するためには、publicメソッドが必要なんだよ。
今日、新しくチームに加わったメンバーとの打ち合わせでその台詞使わせてもらった
上司や同僚の前でｶｯｺｲｲ俺を見せることができたぜぃ
ありがとう
92 ：: 流れを読まずに愚痴。
NUnit-2.4.8-net-2.0 で
> nunit-x86.exe xxxxxTest.dll /exclude:ExcludeCategory /run
とすると起動初回だけ /exclude オプションが無視されてExcludeCategoryカテゴリのテストも実行される。
その後に手動で run ボタンを押すときちんと除外される。
/runselected は前回選択したテストだけ再実行だし、なんかいい方法ない？
93 ：: >>91
単にブラックボックステストとホワイトボックステストの区別を知らないシッタカとして記憶されたことだろう。
94 ：: テストは工数かける事が大事だからな
実行時間を浪費し表面だけをなでるような
テストケースを作る事が理想
そのためには不要なpublicメソッドも作るさ
コーナーケースを叩く行為は厳に戒めること
うっかりバグなんか発見しようもんなら
開発者に恨まれるから
カバレッジはもちろん100%
95 ：: そうか
96 ：: test
97 ：: test
98 ：: ソフトウェア・マネージメントの極意を著名人が解説
―― ソフトウェアテストシンポジウム 2010東京（JaSST'10 Tokyo）レポート
ttp://www.kumikomi.net/archives/2010/02/rp03jass.php
(URLには目を瞑って下さい)
99 ：: マ暦は10年超えてるんだけど、ぼやぼやしてたらテスト関連の知識は
一切習得してなかったことに気がつきました。
テストにもいろんなものがあるみたいだけど、
正直どこからはじめたらいいかぜんぜんわかりません。
多分単体テストとか言うところからはじめるのが、
いいのかなと思っていたりします。
どこから勉強すべきなのでしょうか・・・。
100read 1read
1read 100read TOP カテ一覧スレ一覧削除依頼 ▲ ・　次のスレ 自分が死んだらＰＣのデータを削除するプログラム いもうとデスクトップを実際に作ってみないか？3 【春の恒例】ドワンゴ今年も求人３【２ちゃんねる】 FeliCa でソフトを作りまくるスレ 2ブロック目