207コメント94KB

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

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2008/04/13(日) 00:21:33

プログラムにテストはつきもの
xUnit の効率的なテストコードの書き方やその他テストツールに
ついて語りましょう。

テストツールについて語るスレ
ttp://pc11.2ch.net/test/read.cgi/tech/1030721755/

0002デフォルトの名無しさん

2008/04/13(日) 00:30:00

悪いが、これからは、xUnitではなくBDDの時代。

　　　　　　　　　　　　　　完

0003デフォルトの名無しさん

2008/04/13(日) 00:42:23

前スレ >>996-997

TDD は、テストコードを書くことによって仕様が明確になることを
期待してるから、実装の前にテストコードを書くことを薦めている。

要するに、テストコードは仕様書をよりブレークダウンしたものと
考えればいい。

もちろん全ての仕様がテストコードにできるわけじゃないけど、
多くのあいまいな仕様はテストコードを作成する時点で、あいまい
と言うことがわかるから明確にできると言う効果がある。

プログラムを作成する時点でも同様にあいまいな部分はわかるけど、
一般にプログラムの作成はテストコードの作成より時間がかかるか
ら、プログラムを作成した時点で仕様が明確になっても対応できな
いケースがほとんど。(これが今までの流れでしょ？)

その上に、適切なツールを併用すれば作成したテストコードを用い
て自動でテストができる。実用的にはこっちのメリットも大きいけ
ど、手法としてはどっちかって言うと副次的な効果なんだな。

>>2
手法とツールの区別もついてない奴はこのスレには不要だから、
もうこないでね。

0004デフォルトの名無しさん

2008/04/13(日) 00:49:10

悪いが、これからは、TDDではなくxSpecの時代。

　　　　　　　　　　　　　　完

0005デフォルトの名無しさん

2008/04/13(日) 00:56:26

>ちょっと実装→すぐテスト→ちょっと拡張→またすぐテスト

その最初の「ちょっと」が本当に「ちょっと」なら問題ない
あと、「ちょっと拡張」後のテストで前のテストに失敗していないことを確認できるならおｋ

0006デフォルトの名無しさん

2008/04/13(日) 02:25:06

「テスト駆動“開発”」（TDD）というプラクティスを掲げていますが、実質的にはむしろ「テスト駆動“設計”」なんです。
むしろ、設計をコード・ベースでやったらテストになった、という方が適切だと思います。

0007デフォルトの名無しさん

2008/04/13(日) 07:30:08

>一般にプログラムの作成はテストコードの作成より時間がかかるから、

一般にと言えるほど明確ではない

0008デフォルトの名無しさん

2008/04/13(日) 07:35:54

>>5
「ちょっと」の大きさはプログラマのスキル。
TDDでも「一歩」の大きさは本人の自信に依存すると言っているだろ？

0009デフォルトの名無しさん

2008/04/13(日) 08:16:08

現実にTDDが役に立ってるって人がいるのに、いや、お前は勘違いしてる、
実は役に立ってないんだって説得したいの？

0010デフォルトの名無しさん

2008/04/13(日) 08:40:16

開発手法レベルの話で○○は役に立つ、立たないというのは
そもそも一開発者が判断できることじゃないけどな。
TDDをどれだけのプロジェクトに適用した経験があって
開発要因のスキルのばらつきの中で導入コストがどうで
TDDと従来法の比較でそれぞれバグ発生件数の推移がどうで
それが結果的に開発工数をどのように削減していて
とか真面目にやらんと判断なんかできない

2chのこういう場所で役に立つ立たないというのはどちらも
好き嫌い、俺の性格に合ってる俺には合ってないレベルの感想だな
それが悪いとは言わんしそれ以上を期待するのが間違ってるんだけどな

0011デフォルトの名無しさん

2008/04/13(日) 08:49:16

開発手法レベルで、役に立つ・立たないを合意できないと、使うこともできないの？

0012デフォルトの名無しさん

2008/04/13(日) 08:51:40

>>10
何かを真面目にやれば、「品質」が測定できるとでも？
工数は測定できるがな。

0013デフォルトの名無しさん

2008/04/13(日) 08:54:15

>>12
現実にソフトウェアメトリクスが役に立ってるって人もいるのに、
いや、お前は勘違いしてる、
実は品質なんか測定できないんだって説得したいの？

0014デフォルトの名無しさん

2008/04/13(日) 08:56:12

TDDを使うことによって変化する（した）品質を測定できるのかって聞いてるんだが。
測定できるとでも？

0015デフォルトの名無しさん

2008/04/13(日) 08:59:36

>>14
測定すらできないものの役に立つ立たないを議論できるとでも？

0016デフォルトの名無しさん

2008/04/13(日) 09:02:39

測定なんかしなくていいという立場だが。

0017デフォルトの名無しさん

2008/04/13(日) 09:05:51

ウケル、頼むから釣りと言ってくれ
てか自宅で数十万単位の小銭稼ぎを繰り返すフリーか？

0018デフォルトの名無しさん

2008/04/13(日) 09:07:07

>>17
>>11

0019デフォルトの名無しさん

2008/04/13(日) 09:25:17

>>10
TDDは普通xUnitとあわせてやるもので、TDDのメリットがどれくらいかを測定するためには、
xUnitを使いなれた環境でなおかつTDDを採用していないチームで測定する必要があり、
それは現実的じゃないと思う。

俺もKent BeckのTDD本は読んだが、教条的なTDDには現実味があまり無いと思った。
もともとスキルがある程度ないと実行できないだろうしね。

TDDはガイブインターフェース決定後の実相開始以降の手法だと理解したが、そこでメリットが
あると感じた個人が採用すればいいんじゃないかと思った。

0020デフォルトの名無しさん

2008/04/13(日) 09:26:11

typoしまくりすまん。

0021デフォルトの名無しさん

2008/04/13(日) 09:34:11

>>10
品質測定の可否はともかく、そう言う話は2ch向きじゃないな。とても、文字のみ2048文字では足りない。

話を変えるけど、TDDって難しくね？
馴染んだ奴らには自然のことなんだけど、
例えば一山いくらの人足プログラマにできるかというと、無理だと思う。
何故かって、TDDは設計もしないといけないから。
単に設計するだけじゃなくて、業務要件をこなしつつテストしやすいような設計を、
コード書きながらしないといけない。
言われたとおりコード書くだけの三下プログラマには難しすぎる。

じゃあ、必要なスキルを持ったエンジニアを、工数と期間を踏まえた分だけ
そろえられるかというと、規模によっては無理だろうな。そしたらTDDの導入は困難だ。
前スレでTDD導入の可否は開発手法の影響を受ける、という主張があったけど、
それは結果論で、優秀なエンジニアをそろえられないから
少数の仕様設計者＋下っ端大勢の体勢が不可欠になり、結果としてTDDが導入できない、
って事だと思う。

後は、人数が増えすぎると、設計を個々のエンジニア任せにした時に
意思疎通が難しくなって、てんでばらばらな設計になるって問題も考えられる。
AはAの流儀でTDDで設計&実装し、BはBの流儀でTDDする。
AとBの意思疎通が取れていれば、AとBの書くコードの差異は小さいけど、
人数が多いと意思疎通が難しくなる。
そこで意思疎通を怠ると、Aの設計とコードにBは違和感を覚え、直したくなる衝動になられるだろう。
エンジニアはこういう所にうるさい奴が多いから、後戻りになるかチーム内で不和が生まれるかするかもね。

0022デフォルトの名無しさん

2008/04/13(日) 10:11:32

>>19
自分の印象もそんな感じだな
仕変要求がメールや口頭で飛んで「じゃ、あと、よろしく」な仕事だと
開発のスピード感を維持するためには必然的にTDDにならない？

>>21
これも同意
言い換えれば、エンジニアが強い（＝仕様設計レベルに口を挟める、
お客さんと直接対話できる）立場に置かれていないとTDDは難しいと思う

その意味でケントベックの本ってある意味ストレスがたまらない？
前半くどくど書いてある内容は一定レベルのエンジニアなら紙ぺら３，４枚で済む内容で
本当に知りたいのは最後の方のQ&A集みたいな章、たとえば
「巨大システムをテスト駆動することができるのか」みたいなとこだったり
するんだけど、そっちはあの本では満足のいく答えが全く得られない

0023デフォルトの名無しさん

2008/04/13(日) 10:46:53

>>7
お前さんのところのプロジェクトでは設計工程よりチェックリスト成に時間を
割いてるの？

もしそうなら、それはすばらしいことなので、TDD なんか無視してこれからも
がんばってください。

>>21
色々書いてるけど、結局アホには無理ってこと？

それは、別に TDD に限った話じゃないと思うが。

でも、普通のやり方だとタチの悪いアホが発覚するのはテスト工程に入ってか
らだけど、TDD やってれば製造工程の速い段階で露見する可能性が高いから、
やる意味はあると思う。

>>22
> 「巨大システムをテスト駆動することができるのか」みたいなとこだったり

激しく TDD を勘違いしてない？

0024デフォルトの名無しさん

2008/04/13(日) 11:52:03

>>23
>> 「巨大システムをテスト駆動することができるのか」みたいなとこだったり
>
>激しく TDD を勘違いしてない？

kent beckがか？ｗ

0025デフォルトの名無しさん

2008/04/13(日) 13:35:57

??? 勘違い君、乙なのかな...

0026デフォルトの名無しさん

2008/04/13(日) 14:17:37

語る前に本くらいは

0027デフォルトの名無しさん

2008/04/13(日) 15:05:57

xUnitを使ってるがＴＤＤはしてないとこなんていくらでもあるだろ。
それをそんな奴はほとんど居ないなんて思っちゃう視野の狭さが、信者なんだろうな。

002819

2008/04/13(日) 15:08:36

>>22
> >>19
> 自分の印象もそんな感じだな
> 仕変要求がメールや口頭で飛んで「じゃ、あと、よろしく」な仕事だと
> 開発のスピード感を維持するためには必然的にTDDにならない？

んー、ならない（笑）
red-green-refactoringは、まどろっこすぎて俺には合わない。

> >>21
> これも同意
> 言い換えれば、エンジニアが強い（＝仕様設計レベルに口を挟める、
> お客さんと直接対話できる）立場に置かれていないとTDDは難しいと思う

俺は19に書いたように、TDDって外部設計が終了し、内部設計で言う所の外部インターフェースが
決定し、各タスク（モジュール）が各人にアサインされた後の開発手法だと理解してるから、
要件定義とは関係ないと思ってる。
TDDをうまく使いこなせて、快適だと感じれば使えばいいんじゃない？って感じ。

0029デフォルトの名無しさん

2008/04/13(日) 15:09:12

>>27
そう思ってる奴はお前の脳内にしかいない。

0030デフォルトの名無しさん

2008/04/13(日) 16:03:26

>>28
なるほど。同じTDDでも使い方が違うね。
俺は逆に外部インタフェースがしっかり確定した状態で渡されるなら
あとはコードに落とすだけだから、そういうカッチリした仕事だと
むしろレッド、グリーン、がまどろっこしく感じる。

そういう仕事の場合はシンプルに実装、グリーン、ＯＫ。

0031デフォルトの名無しさん

2008/04/13(日) 16:10:54

おい、外部仕様って言ったら、ユースケースと画面とワークフロー程度だろ。

0032デフォルトの名無しさん

2008/04/13(日) 16:13:08

頑固な派遣テスターはテストツールなんて使いません
http://pc11.2ch.net/test/read.cgi/prog/1207581904/

ただただテキトーにプログラムを触る、それがホントウのテスターなんです！

003319

2008/04/13(日) 19:53:07

>>30
なんか、「外部インターフェース」について、俺と大きなズレがあるけど、まーいいか。

0034>30

2008/04/13(日) 20:05:26

まぁ実際は公開インタフェース含めてリファクタリングの対象となるわけだが、

実装内部の構造について事前に決定せず、
(最初にレッドにするかはともかく)レッド→グリーン→リファクタリング
で確定させるYO!

0035デフォルトの名無しさん

2008/04/13(日) 20:16:30

外部インターフェースって、公開I/Fとか入出力情報とかプロトコルとかだろ。
これが決定した後で「あとはコードに落とすだけ」なんてありえん。

0036デフォルトの名無しさん

2008/04/13(日) 20:58:50

>>30の言うことを解釈すると、外部インターフェースが確定していない状態なら、
レッド、グリーンがまどろっこしく感じないと読めるが、全く意味がわからん。

どういうこと？

0037デフォルトの名無しさん

2008/04/13(日) 21:17:29

>>30
> 俺は逆に外部インタフェースがしっかり確定した状態で渡されるなら
> あとはコードに落とすだけだから、

要するに、コーダー君と言うことかな？

0038デフォルトの名無しさん

2008/04/24(木) 01:52:12

158 ：仕様書無しさん：2008/04/13(日) 00:40:17
このコードいじり悩み悩み悩み続けた
既に書いてあるはず？もマジで見当たらない
繰り返すと過去にできていた機能が消えた
このすごい　バグが最後で最後最後か？
寝させろ・「わーっ！！」　マシンが古くて砕けた
そりゃも体調は落ちる　僕の胃にピロリがw

0039デフォルトの名無しさん

2008/06/05(木) 01:36:20

Seleniumの話題はここでおk？

0040デフォルトの名無しさん

2008/06/05(木) 08:32:39

テスターはツール扱い？

0041デフォルトの名無しさん

2008/06/08(日) 03:32:41

反復的にこき使われるという点ではyes

0042デフォルトの名無しさん

2008/06/08(日) 07:48:20

工期圧縮で真っ先に短縮されるのがテスト工程。
客からのクレームで真っ先に責め立てられるのがテスト工程。
やってらんねーよ！

0043デフォルトの名無しさん

2008/06/09(月) 19:41:39

テストしてない工程表を作ればいいんじゃね？

入力チェック・・・工期圧縮で省略
トランザクションチェック・・・工期圧縮で省略

0044 ◆UWAAAAAA..

2008/07/30(水) 13:48:51

Test

0045デフォルトの名無しさん

2008/08/23(土) 20:19:13

自分からテスト専門です、って宣言してる派遣テスターって何なの？

将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。

俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。

今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？

あ～あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ～、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。

派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！

0046デフォルトの名無しさん

2008/08/23(土) 20:39:35

板違い

0047デフォルトの名無しさん

2008/08/23(土) 21:09:56

>>45
このスレ的にはそういうバカテスターの問題も避けて通れないよな
そういうヤツが一人ういるとテストツールの普及が妨害されるからね

0048デフォルトの名無しさん

2008/08/23(土) 21:23:58

>>45
派遣同士底辺で仲良くしてなよ。

>>47
そう言う話題はマ板でやってくれ。

0049デフォルトの名無しさん

2008/08/23(土) 22:08:41

過疎スレなんだから目くじらたてんなよ

0050デフォルトの名無しさん

2008/08/23(土) 23:49:49

>>45はコピペ

0051デフォルトの名無しさん

2008/08/25(月) 02:51:04

コソコソ告げ口
契約切られて逆恨み、愚痴をリピート
それが底辺派遣テスター

0052デフォルトの名無しさん

2008/08/25(月) 05:13:17

GUI部分の効果的なテストツールってない？
みんなどうやって品質上げてるの？
実装とテストの大半が画面周りに費やしちゃってハゲそうれす

0053970

2008/08/25(月) 08:27:32

>>52
HTMLならあるよ。

0054デフォルトの名無しさん

2008/08/25(月) 09:08:56

GUIイベントの記録と疑似再生のツールぐらい、普通につくってないか？

0055デフォルトの名無しさん

2008/09/11(木) 07:54:55

俺もこの前まで派遣テスターやってたけど、派遣テスターって渡されたテストをやるだけじゃないの？
10年以上続いてる大きいプロジェクトだからか、全体図もよく分からず仕様書なんかも「見たければ見てもいいよ」くらいの感じで、
自分で仕様書作るなんてありえなかったんだけど

0056デフォルトの名無しさん

2008/09/11(木) 22:49:07

そりゃ派遣テスターって言っても形式的にはテスト実施だけのケースから
テスト全体計画立案まで含むケースまであるだろ。

まあ、テスト全体計画立案まで派遣に任せるようなところは開発からほと
んど丸投げ状態だと思うが。

0057デフォルトの名無しさん

2008/09/11(木) 23:05:43

立案書じゃなく仕様書の話だろ

0058デフォルトの名無しさん

2008/09/11(木) 23:18:47

立案書？なんだそれ。

0059デフォルトの名無しさん

2008/09/11(木) 23:41:47

テスト全体計画立案

0060デフォルトの名無しさん

2008/09/12(金) 21:24:15

いや、別に立案書とか言う名前のドキュメントがあってもいいんだが、
あまり聞いたことないから聞き直しただけだよ。

ちなみにうちでは、テスト全体計画立案の内容を書くのはテスト計画書
という名前のドキュメント。

0061デフォルトの名無しさん

2008/09/13(土) 04:27:33

55の仕様書を56がテスト計画立案と勘違いしてる

0062デフォルトの名無しさん

2008/09/13(土) 07:27:55

>>56 は、>>55 の

> 俺もこの前まで派遣テスターやってたけど、派遣テスターって渡された
> テストをやるだけじゃないの？

についてのレスだよ。

そもそも >>55 に書いてある「仕様書」は、テスト仕様書なのか設計仕様
書なのかもはっきりしないからあえて無視した。

で、その話と「立案書」ってなんか関係あるのか？

0063デフォルトの名無しさん

2008/09/14(日) 19:25:40

「見たければ見てもいいよ」な仕様書なんてあるのか？

0064デフォルトの名無しさん

2008/10/16(木) 00:34:25

>>63
「誰も見てないよ」な仕様書ならある

0065デフォルトの名無しさん

2008/11/17(月) 19:32:06

最近ratproxyとか使い始めて思ったんだけど、これってサイトの脆弱性を見つけて攻撃してやろうとしている攻撃者にとっても有用なツールだよね。
サイト巡回してるだけでどこに脆弱性あるか分かるんだから。

こういう悪意の攻撃者にヒント与えるのを簡単にしていることってあんま問題になったりはしないんですかね？？

0066デフォルトの名無しさん

2008/11/18(火) 22:36:52

>>65
開発者・設計者も使えるんだぜ？

0067デフォルトの名無しさん

2008/11/30(日) 05:57:46

>>65
むしろ公開されていることに感謝かな。
悪意のある人はそういうツールを作って自分だけで使うだろうから。

0068デフォルトの名無しさん

2009/02/07(土) 19:46:48

すみません
テスト駆動開発って普通に使ってるんですか？

自分、最近JUnit使ってテスト駆動開発やれと言われたのですが、あまりのめんどくささに死にそうです
たとえば、単なるDTOに関しても、テストするように言われてますが、フィールドが3個、getterが3個、コンストラクタは1個(引数はフィールドに代入する3個)のDTOテストするにも一苦労です
publicなメソッドを全てテストせよと言われてるのですが、getterごとにテストするたびに似たようなテストコード書き、そのたびにコンストラクタを少しずつ変えていくなどテスト駆動開発を忠実に守ると死にそうです
これ、みなさん普通にやってるんですか？
もう、会社辞めたい

0069デフォルトの名無しさん

2009/02/07(土) 21:38:16

そんなレベルのテストだったら30秒で書けるだろ

0070デフォルトの名無しさん

2009/02/07(土) 21:53:53

>>68
DTOくらい、IDEなりXDocletなりで自動生成するだろ。
そんな、ツールが自動生成するコードはテストしない。
ツールのバグを疑うなら、ツールのテストケースを使って検証すべきであり、
ツールの出力すべてをテストする必要はない。

お前は一体何をテストさせているつもりなのかと、上司に聞いてみろ。（聞けたらね）

0071デフォルトの名無しさん

2009/02/07(土) 22:01:55

そんなくだらんことで思い悩んだりバトルするより、public methodのカバレッジ100%のテストをさくっと作れよ

0072デフォルトの名無しさん

2009/02/08(日) 22:35:06

レスありがとうございます

>>69
失敗するテストを書く、テストをパスするコードを書く、リファクタリングをするを真面目にやると30秒では無理じゃないですか？
たとえば、getA、getB、getCの3個のテストを考えると
最初にgetAのテストを書く→Aを引数にとるコンストラクタを作る→getA実装→三角測量でパスするまで続ける
次にgetBのテストを書く→Aを引数にとるコンストラクタをA、Bを引数に取るコンストラクタに変更→getAのテストに修正の必要発生→グダグダの上すごい作業量になる
とかなりませんか？

>>70
そういう考え方もありますね
DTOは確かに自動生成すべきでしょうね
上の例でDTOを上げたのは、一番最初に思いついた例だからです
ちなみに、自分はテスト自体は必要だし、JUnitも有効なツールと考えています
しかし、テスト駆動開発はあまりにも無駄な作業が多いのでは？と疑問に思ってます
各クラスの使用をしっかり決めて、危険そうな箇所だけテストケース書くとかじゃだめなのかな？
テストが仕様書だと言ってもプログラマ以外は認めてくれないと思いますし

>>71
疑問なのですが、カバレッジ100%のテストはさくっと作れますかね？
カバレッジ100%の意味がどの程度なのかわからないのですが、
例外処理とか入れたら細かいクラスでもそれなりの作業量になるし、
ましてや複数のクラスを統括するクラスは凄まじいテストパターンが必要な上、
細かいクラスで行ったテストとほぼ同じ作業になりそうですし

0073デフォルトの名無しさん

2009/02/08(日) 23:01:58

コードの網羅率のカバレッジじゃなくて、methodの網羅率100%のテストってこと。
それが求められてるんだろ？
それと、テストが必要かどうかが既にわかってるのは、元コードを書いた人間だけ。
外部の人間がメトリクスを取るとき、いちいち元コードの内容を見て、テストが無い
ことの妥当性を確認するのは手間だろ。だからさくっと作れって。

0074デフォルトの名無しさん

2009/02/08(日) 23:09:17

つか、悩んでるならTDD本まず読めって

0075デフォルトの名無しさん

2009/02/08(日) 23:15:31

>たとえば、getA、getB、getCの3個のテストを考えると
>最初にgetAのテストを書く→Aを引数にとるコンストラクタを作る→getA実装→三角測量でパスするまで続ける
>次にgetBのテストを書く→Aを引数にとるコンストラクタをA、Bを引数に取るコンストラクタに変更→getAのテストに修正の必要発生→グダグダの上すごい作業量になる

これがまず間違ってる。
あるオブジェクトがオブジェクト足りうるのに必要な情報が三つあるなら、その三つを引数に取る
コンストラクタのテスト・実装から始める。
それがパスし、なおかつ外部I/Fが必要なら、getterのテストを追加する。
さらに、コードが明白なら、三角推量なんかしないでよい。

0076デフォルトの名無しさん

2009/02/08(日) 23:48:03

>>73
さくっと作れの意味がよくわからないのですが、必要なテストを自分で考え実装しテストするという考えだと、テスト「駆動」開発にならないきがするのですが

>>74
本とwebで情報収集はしました
その結果、真面目にテスト駆動開発する意味がわからず悩んでます

>>75
コンストラクタのテストとは具体的に何をやるのでしょうか？
リフレクション使ってprivateなフィールドの状態確認するのですか？
解説者により内容が違うのですが、基本的にテスト駆動開発ではpublicなメソッドに対しテストを行い、内部状態などを見るのは別のテストという記述を見たので、それにしたがってます

0077デフォルトの名無しさん

2009/02/09(月) 00:19:03

TDDの目的は品質を保証することだ。テストコードを書くのが目的じゃない。
目的と手段をごっちゃにしちゃダメだよ。

0078デフォルトの名無しさん

2009/02/09(月) 00:35:31

今の現場　Nunit　とか言う糞面倒臭いツールを使っていてそれを
必ず通さないと駄目！！って事になってる。
わざわざそのNunitを通す為のプログラムも作成しなくてはならないとか
糞杉。

テストツールって意味あるのか？
マジで無駄に工数がかかってしょうがないと思う。

あと訳の分からん無駄な独自フレームワークを使ってるプロジェクトとかも最悪。

0079デフォルトの名無しさん

2009/02/09(月) 00:46:01

うちは、工数がかかって仕方ないから、TDDやめたクチ
リリースしてバグ出てから、バグとった方が圧倒的に効率的。
どうせ、TDDやっても手動テストする時間くらいは別にとるんだしね。

第一、そのバグ修正とかが、必要かどうかってのは運用してみないとわからない。
そんなところをあらかじめ工数かけてつぶす意味がわからない。

品質がよいものを作るのが目的ではなくて、顧客が満足するものを作るのが目的だからね。

結局、TDDやめたら工数的に2倍くらい早くなった

0080デフォルトの名無しさん

2009/02/09(月) 00:51:12

>>72
>各クラスの使用をしっかり決めて、危険そうな箇所だけテストケース書くとかじゃだめなのかな？

主観だと断っておくとして、
テスト駆動開発は、テスタビリティと保守性に優れた設計および実装と、
結果として得られる自動テストスイートを、
低コストで安定して得るための方法論であり、
その結果得られる安心と勇気こそが、TDDの価値であると思っている。

そのためのアレンジは認められてしかるべきだと思うし、
逆に、テスト駆動開発の原則に縛られて生産性を損なうようでは本末転倒。
「こんなの自明で、より最適な設計や実装もなければ、バグが入り込む余地もない」と
開発者が皆思うようなところは、TDDはしない。
つまり、1+1=2をTDDしない、ということ。

ただし、注意しなければならないのは、「その設計と実装の正当性はホントに自明か？」ということ。
あなたが当たり前のように実装したコードに、実はバグが潜んでいるかもしれない。
または、今月のあなたが最適と思って設計し実装したコードが、来月のあなたにとってはクソのように思えるかもしれない。

そういう判断は難しい。あなたのいう「危険でない」は、どの程度信用できるのか？
安心して信用できるまでは、TDDのルールを破るべきではない。

ただし、比較的判断しやすいところとして、
>>70で挙げたような自動生成されたコードがある。これはTDDしなくていいだろう。
getter/setterだけでなく、コンストラクタを自動生成できるツールもあるので
それらの機能の利用を薦める。IDEならEclipseとか。
つうか、DTOをネタにするのは、この辺で止めた方がいいね。

まとめると、TDDは安心と勇気を手に入れるための手段なので、
安心と勇気が損なわれない程度にはアレンジしてよし。
ただし勇気と蛮勇の違いに注意せよ。

0081デフォルトの名無しさん

2009/02/09(月) 01:37:34

色々とレスありがとうございます
自分なりに考えて部署の人に話してみます(非公式な立場で)

0082デフォルトの名無しさん

2009/02/09(月) 12:42:34

>>76
>コンストラクタのテストとは具体的に何をやるのでしょうか？
インスタンス化してエラーが発生しないことを確認するコード。

>リフレクション使ってprivateなフィールドの状態確認するのですか？
しない。Moneyクラスの例読んだんだろ？

>解説者により内容が違うのですが、基本的にテスト駆動開発ではpublicなメソッドに対しテストを行い、内部状態などを見るのは別のテストという記述を見たので、それにしたがってます
違う。publicメソッドに対してテストを行うのではなく、要求にしたがってテストを書く。
その要求を実現するためには、publicメソッドが必要なんだよ。

>さくっと作れの意味がよくわからないのですが、
だから、publicメソッドを100%カバーするテストが要求されてるんだから、そのことに対してあれこれ上司と
バトルして時間使うより、さくっと作れって言ってるんだけど、意味わかんない？

>必要なテストを自分で考え実装しテストするという考えだと、テスト「駆動」開発にならないきがするのですが
本読んだんだろ？
気のせいだ。

0083デフォルトの名無しさん

2009/02/09(月) 12:44:19

ひょっとして「さくっと」の意味がわからないのか？
さっさと作れってことだ。

0084デフォルトの名無しさん

2009/02/09(月) 12:48:14

>>80
管理する側の観点から見ると、プログラマの資質もコードの質もテストコードの質もわからないんだから
（もちろんコード見りゃわかるが）、管理上publicメソッドを100%網羅するテストは最低限書いとけってのは
ありだと思う。自動チェックできるしね。

なので、このpublicメソッド100%の話は、TDDの精神とは別に考えるべき項目だと思う。

0085デフォルトの名無しさん

2009/02/12(木) 02:06:09

みんなでテストツール作りませんか

0086デフォルトの名無しさん

2009/02/12(木) 02:11:55

まずは仕様をageようか

0087デフォルトの名無しさん

2009/02/12(木) 02:15:47

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でがんばればいけるかな？

0088デフォルトの名無しさん

2009/02/12(木) 02:37:47

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＾
所で宍道湖つかってる人いる？
(略)

0089デフォルトの名無しさん

2009/02/12(木) 02:42:27

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使ってる人が多いだろうし，使ってるだろうけど

0090デフォルトの名無しさん

2009/02/12(木) 03:00:40

まずは仕様をageようか

0091デフォルトの名無しさん

2009/02/14(土) 19:58:02

>>82
>違う。publicメソッドに対してテストを行うのではなく、要求にしたがってテストを書く。
>その要求を実現するためには、publicメソッドが必要なんだよ。
今日、新しくチームに加わったメンバーとの打ち合わせでその台詞使わせてもらった
上司や同僚の前でｶｯｺｲｲ俺を見せることができたぜぃ
ありがとう

0092デフォルトの名無しさん

2009/02/14(土) 22:26:14

流れを読まずに愚痴。
NUnit-2.4.8-net-2.0 で
> nunit-x86.exe xxxxxTest.dll /exclude:ExcludeCategory /run
とすると起動初回だけ /exclude オプションが無視されてExcludeCategoryカテゴリのテストも実行される。
その後に手動で run ボタンを押すときちんと除外される。
/runselected は前回選択したテストだけ再実行だし、なんかいい方法ない？

0093デフォルトの名無しさん

2009/02/15(日) 06:58:55

>>91
単にブラックボックステストとホワイトボックステストの区別を知らないシッタカとして記憶されたことだろう。

0094デフォルトの名無しさん

2009/03/16(月) 16:02:12

テストは工数かける事が大事だからな
実行時間を浪費し表面だけをなでるような
テストケースを作る事が理想
そのためには不要なpublicメソッドも作るさ

コーナーケースを叩く行為は厳に戒めること
うっかりバグなんか発見しようもんなら
開発者に恨まれるから

カバレッジはもちろん100%

0095デフォルトの名無しさん

2009/04/14(火) 23:58:11

そうか

0096デフォルトの名無しさん

2010/01/03(日) 05:04:50

test

0097デフォルトの名無しさん

2010/02/08(月) 19:12:51

test

0098デフォルトの名無しさん

2010/02/08(月) 20:38:23

ソフトウェア・マネージメントの極意を著名人が解説
―― ソフトウェアテストシンポジウム 2010東京（JaSST'10 Tokyo）レポート
ttp://www.kumikomi.net/archives/2010/02/rp03jass.php

(URLには目を瞑って下さい)

0099デフォルトの名無しさん

2010/02/20(土) 13:20:49

マ暦は10年超えてるんだけど、ぼやぼやしてたらテスト関連の知識は
一切習得してなかったことに気がつきました。

テストにもいろんなものがあるみたいだけど、
正直どこからはじめたらいいかぜんぜんわかりません。

多分単体テストとか言うところからはじめるのが、
いいのかなと思っていたりします。

どこから勉強すべきなのでしょうか・・・。

0100デフォルトの名無しさん

2010/02/20(土) 13:26:56

>>99
BDD(振る舞い駆動開発)やTDD(テスト駆動開発)
詳しくはぐぐれ

俺も今挑戦中。

0101デフォルトの名無しさん

2010/03/17(水) 18:46:47

むー
gcovで網羅確認とかしてるんだが
while節の通過数おかしいような気がする。

上流から来た数とループ内の数の合計かと思っていたら
上流から来た数×２＋ループ数になってるような

これで正しいとか、正しくないとか、正しいなら数え方の根拠おしえてくだされ

ちなみに
gcc version 4.5.0 20090820 (experimental) (GCC)
gcov (GCC) 4.2.1 20070719 [FreeBSD]
です。

0102デフォルトの名無しさん

2010/03/18(木) 11:37:33

>>101
正しくないと思う最小のコードとローカルの実行結果、そして期待値を書け。

0103デフォルトの名無しさん

2010/03/18(木) 23:52:08

>>101

gcc -O0 -fprofile-arcs -ftest-coverage -o test test.c
./test
gcov test.c
cat test.c.gcov

-: 0:Source:test.c
-: 0:Graph:test.gcno
-: 0:Data:test.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:#include <stdio.h>
1: 2:int main()
-: 3:{
1: 4: int i = 0;
-: 5:
7: 6: while (i < 5) {
5: 7: i++;
-: 8: }
1: 9: printf("%d\n", i);
1: 10: return 0;
-: 11:}

6行目のwhileの実行数は7となっているが6が正しいのでは？
他の例でも
ループの内部実行数（この場合はi++の行、5回)＋ループに入る前（この場合1回)×２
にすべてなっているみたい

0104デフォルトの名無しさん

2010/03/21(日) 14:46:34

>>103 試してみた
$ gcc --version
gcc (GCC) 4.3.4 20090804 (release) 1
...
$ gcc -O0 -fprofile-arcs -ftest-coverage -o test test.c
$ ./test
5
$ gcov test.c
...
$cat test.c.gcov
-:  0:Source:test.c
-:  0:Graph:test.gcno
-:  0:Data:test.gcda
-:  0:Runs:1
-:  0:Programs:1
-:  1:#include <stdio.h>
-:  2:int main()
1:  3:{
1:  4:  int i = 0;
-:  5:
7:  6:  while (i < 5) {
5:  7:    i++;
-:  8:  }
1:  9:  printf("%d\n", i);
1: 10:  return 0;
-: 11:}

0105104

2010/03/21(日) 14:54:13

こっちの手元でも、「while(i<5){」の実行回数は7回になるね。
あと、lcov を併用してみたら、こちらは6回って表示された。

lcov をインストール (perlが必要)
$ wget http://downloads.sourceforge.net/ltp/lcov-1.8.tar.gz
$ tar zxf lcov-1.8.tar.gz
$ cd lcov-1.8
$ make install
$ cd ..

lcovでカウンタリセット、testを実行、lcovで結果を蒐集、genhtmlでHTMLレポートを生成
$ lcov -d . -z
$ ./test
5

$ lcov -d . -c -o lcov.dat
$ genhtml -o html lcov.dat
（html/index.html をWebブラウザで開いて結果を見る)

0106デフォルトの名無しさん

2010/03/22(月) 09:59:24

>>101
ソース見るしか、意図なのかバグなのかわからないと思う。

0107デフォルトの名無しさん

2010/03/22(月) 20:06:24

>>104
さんくす
lcov試せなかったので参考になりました
lcovが違う回数出すとすると、gcdaのデータから
表示するときにアークのパスを数え間違えている
可能性が高いのかなぁ

>>106
ソースはちょっと見てみたが、計数のところは、
じっくり読まないとよくわからなそう
＃gnu表記は俺的には読み難いというのもあるが
引き続き時間見つけてソース読んでみます

もっともソース読んでも、バグか意図的かはわからんかもしれないけど。
意図的ならその意図（意味）を知りたいわけだし。
該当部に丁重にコメントが書いてあるとかなら別だけど…

「7回ってのがこういう意味じゃない？」って心当たりとか
引き続き、なにか気付いた点があったら教えてください。

0108104

2010/03/23(火) 00:00:27

gcc 3でも試してみた。こちらはwhile(i<5)の通貨回数は6になるね。
$ gcc-3 --version
gcc-3 (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
...
$ gcc-3 -O0 -fprofile-arcs -ftest-coverage -o test test.c
$ ./test
5
$ gcov-3 test.c
$&npsp;cat&npsp;test.c.gcov
&npsp;-:&npsp;0:Source:test.c
&npsp;-:&npsp;0:Graph:test.gcno
&npsp;-:&npsp;0:Data:test.gcda
&npsp;-:&npsp;0:Runs:1
&npsp;-:&npsp;0:Programs:1
&npsp;-:&npsp;1:#include&npsp;<stdio.h>
&npsp;-:&npsp;2:int&npsp;main()
funon&npsp;main&npsp;called&npsp;1&npsp;returned&npsp;100%&npsp;blocks&npsp;executed&npsp;100%
&npsp;1:&npsp;3:{
&npsp;1:&npsp;4:&npsp;&npsp;int&npsp;i&npsp;=&npsp;0;
&npsp;-:&npsp;5:
&npsp;6:&npsp;6:&npsp;&npsp;while&npsp;(i&npsp;<&npsp;5)&npsp;{
&npsp;5:&npsp;7:&npsp;&npsp;&npsp;&npsp;i++;
&npsp;-:&npsp;8:&npsp;&npsp;}
&npsp;1:&npsp;9:&npsp;&npsp;printf("%d\n",&npsp;i);
&npsp;1:10:&npsp;&npsp;return&npsp;0;
&npsp;-:11:}

0109104

2010/03/23(火) 00:02:38

なお、lcovは>>104-105と変わらず&npsp;(whileの通貨回数は6）
&npsp;1&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;:&npsp;#include&npsp;<stdio.h>
&npsp;2&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;:&npsp;int&npsp;main()
&npsp;3&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;1&npsp;:&npsp;{
&npsp;4&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;1&npsp;:&npsp;&npsp;&npsp;int&npsp;i&npsp;=&npsp;0;
&npsp;5&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;:&npsp;
&npsp;6&npsp;[&npsp;+&npsp;&npsp;+&npsp;]:&npsp;6&npsp;:&npsp;&npsp;&npsp;while&npsp;(i&npsp;<&npsp;5)&npsp;{
&npsp;7&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;5&npsp;:&npsp;&npsp;&npsp;&npsp;&npsp;i++;
&npsp;8&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;}
&npsp;9&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;1&npsp;:&npsp;&npsp;&npsp;printf("%d\n",&npsp;i);
10&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;1&npsp;:&npsp;&npsp;&npsp;return&npsp;0;
11&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;&npsp;:&npsp;&npsp;&npsp;:&npsp;}

0110104

2010/03/23(火) 00:04:58

タイポしたので、やりなおし。
$ gcc-3 --version
gcc-3 (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
...
$ gcc-3 -O0 -fprofile-arcs -ftest-coverage -o test test.c
$ ./test
5
$ gcov-3 test.c
$ cat test.c.gcov
-:  0:Source:test.c
-:  0:Graph:test.gcno
-:  0:Data:test.gcda
-:  0:Runs:1
-:  0:Programs:1
-:  1:#include <stdio.h>
-:  2:int main()
function main called 1 returned 100% blocks executed 100%
1:  3:{
1:  4:  int i = 0;
-:  5:
6:  6:  while (i < 5) {
5:  7:    i++;
-:  8:  }
1:  9:  printf("%d\n", i);
1: 10:  return 0;
-: 11:}

0111104

2010/03/23(火) 00:05:44

タイポしたのでやり直し、その2。lcovは>>104-105と変わらず (whileの通貨回数は6）
1         :   : #include <stdio.h>
2         :   : int main()
3         : 1 : {
4         : 1 :   int i = 0;
5         :   :
6 [ +  + ]: 6 :   while (i < 5) {
7         : 5 :     i++;
8         :   :   }
9         : 1 :   printf("%d\n", i);
10         : 1 :   return 0;
11         :   : }

0112デフォルトの名無しさん

2010/03/24(水) 07:39:50

ソースコードと機械語が1対1対応しないからしょうがないことだと思うけどね。

0113デフォルトの名無しさん

2010/04/02(金) 00:43:06

ちょっとすれ違いかもしれないですが質問させて下さい

最近同値分割法を習ったのですが、
入力が質的データの場合に何を持って同値とするかの判断ができないです

例えば入力がメールアドレスの場合は、
どういった視点から分割するのがよいのでしょうか

0114デフォルトの名無しさん

2010/04/02(金) 10:23:13

>>113
どうしてぐぐらないのか。
http://app.f.m-cocolog.jp/t/typecast/160889/155415/5035184

0115デフォルトの名無しさん

2010/04/02(金) 23:23:20

>>114
ググりましたが、自分のものにはできませんでした

例えばメールアドレスといっておいてなんなんですが、
未知のデータに対しても同値分割法を適用できるようになりたいので
本当に聞きたいことは、経験豊かな人がどのように基準を決め、どの程度に分割するのかということです

0116デフォルトの名無しさん

2010/04/03(土) 08:07:38

>>115
まず、テスト関連の書籍を数冊読んでから出直せ

0117デフォルトの名無しさん

2010/04/08(木) 12:37:56

>>91
これよくわからない

テスト駆動でコード書くと、おのずとpublicになるの？
privateでテストしたいのだっていっぱいでてくると素人目線では思うのだけど、TDDになれてくるとそうはならないの？

0118デフォルトの名無しさん

2010/04/08(木) 21:45:46

>>117
テスト以前の問題じゃね？
要求に基づいて作るってことは、要求を機能化（仕様化）してから実装するということで、
その機能は public なはず（ public じゃなきゃプログラム外からは直接使えない
わけだから要求を実現したことにならない　）って話でしょ。
で、TDD の違うところは、要求を機能化した後、
その仕様に基づいた実プログラムを作るより先に、
テストコードを書く、ということでしょ。
TDD だからメソッドが public になるわけじゃない。
「なんたらドリブン」というのは、順番の話であって、
スコープは直接関係無い。

0119デフォルトの名無しさん

2010/04/09(金) 00:24:36

>>118
レスサンクス、なるほどーわかりやすい

さらにレベルの低い質問かもしれないけど、メソッドがパブリックなのってそれほど悪いことじゃないのかな？

フィールドはダメで、メソッドも基本privateで作るように考えていて、どうしても必要な時だけプロテクテッドやパブリックにするんだけども、そうすることが安全でOOP的だと思ってたけど間違ってたのかな

あと、個人でアプリとかゲーム作ってるんだけど、そういうことも影響するのかな？

だから自分のコードは基本的にprivateばっかりで、これじゃほとんどテストできないけど、どうすればいいんだろう？みんなどうしてるんだろう？と思ってこのスレ覗いてみた感じ

0120デフォルトの名無しさん

2010/04/09(金) 00:52:32

テスト対象のクラスとテストケースを同一パッケージにおいて、
テストの時だけ、どうしても公開したいメソッドがあったら、
そのメソッドをパッケージプライベートスコープで定義してる。
ソースを置くフォルダは分けるけどね。

ただ、テストが難しくなるというのは、何らかの設計上の問題がある予兆、
というのがTDDの考え方なので、悩んだら設計変更まで含めて考えるのもあり。

例えば、プライベートメソッドが巨大化して別途テストしたくなるほどになったら、
そこを切り出して別クラスにすべきかもしれない。
また、メソッドの実行結果が、副作用として複雑に現れるようなら
（例えば呼び出されたオブジェクトの複数のプロパティに分散してセットされるなど）
メソッドの戻り値に集約できないか検討した方がいいかもしれない。
一般的に、メソッドの副作用は複雑さを上げバグの温床となりやすい。

この辺の話題でお薦めの本は、「リファクタリング」と「レガシーコード改善ガイド」だね。

0121デフォルトの名無しさん

2010/04/09(金) 11:50:04

>>119
外部に公開する機能(I/F)がpublic。それ以上でも以下でもない。

0122デフォルトの名無しさん

2010/04/09(金) 12:49:04

>>121
原則論ではそうなんだが、それだけ考えていると巨大なGodクラスが生まれて
テストが困難になりTDDが破綻する。
テスト対象のクラスが大きくなりテストが難しくなってきたら、
クラスやメソッドをテストし易い形に分割し再設計することが必要。
要はリファクタリングだ。

このリファクタリングとユニットテストは相互依存の関係にある。
安全にリファクタリングを行うには、整備されたユニットテストが必要になるし、
ユニットテストを継続的に維持し続けるには、テストし易い設計への
リファクタリングが必要になる。

リファクタリングの結果、外部に公開する必要のないクラスやメソッドが
生まれるが（この場合はクラスの外部ではなく、モジュールの外部）、
こいつらはpublicでなくてもいいね。
Javaならパッケージプライベートが適切。
テストケースクラスを同一パッケージで宣言すれば、ユニットテストからも
参照できるし。

ここまではTDD前提で書いたが、たとえTDDを実践しないとしても、
テストし易い設計へのリファクタリングを考慮していないと、
テストケースの実装は大きな困難を伴う。
ソフトウェアの成長と共に実装難易度は高まり、いずれメンテ不可能になるだろう。

0123デフォルトの名無しさん

2010/04/09(金) 15:36:15

>>122
そもそもTDDがなんなのかわかってないっぽい。

0124デフォルトの名無しさん

2010/04/09(金) 16:56:27

>>122
God Classはもちろん良くないが、TDDでdrivenしている限り、God ClassだろうがTDDは破綻しないのでは？

0125デフォルトの名無しさん

2010/04/09(金) 21:24:08

厳密にTDDだけで開発していくと、全部もしくはほとんどがpublicメソッドになる？

0126デフォルトの名無しさん

2010/04/10(土) 04:05:33

はぁ？

0127デフォルトの名無しさん

2010/04/10(土) 05:56:28

>>125
TDD かどうかに関係なく、
全てのユニットの全てのメソッド（関数）について
テストケースを用意しようとするとそうなる。
でも、TDDはそういうことを要求してないし、
TDDでない開発でも一般的には多分そういうことは行われてない。

まあ正直、「全て」って言葉を連発する奴とは仕事はしたくないな。
（上司だと最悪）

0128デフォルトの名無しさん

2010/04/10(土) 07:46:38

>>127
> TDD かどうかに関係なく、
> 全てのユニットの全てのメソッド（関数）について
> テストケースを用意しようとするとそうなる。

ならねーよ。

0129デフォルトの名無しさん

2010/04/10(土) 07:59:47

　　　　？
　　　∧∧
　　 (,,ﾟДﾟ)
　　/　　|
～ＯＵＵつ

0130デフォルトの名無しさん

2010/04/10(土) 09:18:24

リファクタリングによって、publicメソッドからprivateメソッドをいくつか抽出したとして、
そのprivateメソッドをpublicにしないとテストできないという主張なのかな？
だとしたら、リファクタリング前のpublicメソッドもテストできないということになるよ？

0131デフォルトの名無しさん

2010/04/10(土) 09:23:35

それと、TDDって網羅的なテストスィートを用意することでもないし、結果的にそれが揃う手法でもないよ。
確かに、TDDのマントラは、red-green-refactoringだけど、そのrefactoringはファウラー本で言うところの
リファクタリングじゃないよ。
ごっちゃにすると話がややこしくなる。

0132デフォルトの名無しさん

2010/04/10(土) 09:40:47

なんかいろいろ勘違いしてると思う。
あわててる人に何か言っても混乱が増えるだけなので、今は指摘しないけど。
とりあえず、最初の数行の印象だけで性急にレスせずに、
落ち着いて最後まで読んで意味を理解してからレスしたほうがいいと思う。

0133デフォルトの名無しさん

2010/04/10(土) 09:47:54

最後まで読んだ結果のレスだけど。

TDDってこれから書くコードをどうやって書くかの方法論だから、それが破綻するという意味がわからない。

0134デフォルトの名無しさん

2010/04/10(土) 09:51:01

それと、God classについての認識も俺と違ってる気がする。
http://c2.com/cgi/wiki?GodClass

God classだからテストしづらくなるんじゃなくて、テストしづらいコードだからテストしづらいんじゃないか？
まぁトートロジーなんですけど。

0135デフォルトの名無しさん

2010/04/10(土) 10:02:46

そもそもTDDはテスト手法じゃないと言うことがわかってないっぽい。
だからTDDの文脈でテストケースとかいう単語が出てくる。

0136デフォルトの名無しさん

2010/04/10(土) 10:22:29

1.TDDで書くためのtodoリストを書く
↓
2.まずテストを書く=レッド
↓
3.対象のメソッドを書く(もちろんpublic)=グリーン
↓
4.リファクタリング
↓
繰り返し

厳密にこればっかり繰り返したら、public以外のメソッドはほとんど出てこないんじゃない？ってことを聞きたかった

(4)から派生してprivateなメソッドを書くことがあるかもしれんけど、それはテストを必要としないような内容であるべきで、そうじゃないなら、それもまた先にテストを書いてpublicメソッドにすべきなんじゃないかと。

0137デフォルトの名無しさん

2010/04/10(土) 10:22:50

>>120
> ただ、テストが難しくなるというのは、何らかの設計上の問題がある予兆、
> というのがTDDの考え方なので
いや、全然違うよ・・・

0138デフォルトの名無しさん

2010/04/10(土) 10:25:26

>>136
だから、TDDってテスト手法じゃないんだってば。

0139デフォルトの名無しさん

2010/04/10(土) 10:30:02

厳密に言うと、mainのみpublicであとは全部privateでいいね

0140デフォルトの名無しさん

2010/04/10(土) 10:41:27

>>136
ケントベックのTDD本読んでから出直せ

0141デフォルトの名無しさん

2010/04/10(土) 10:42:13

>>138
うん、駆動に使うだけでしょ？
>>136はどこがそうなってない？

0142デフォルトの名無しさん

2010/04/10(土) 10:43:02

>>140
読んだ

0143デフォルトの名無しさん

2010/04/10(土) 10:46:05

実際にケントベックの入門書にはprivateどころかprtectedなメソッドへのテストコードの書き方すらでてこないよね
privateなメソッドはテストしなくてもいい、みたいな考え方もある、とも書いてるし

0144デフォルトの名無しさん

2010/04/10(土) 10:49:27

少なくとも3～4人がレスしてると思うんだが、
一人、自分以外のレスは同一人物だと思い込んでる
奴がいないか？

0145デフォルトの名無しさん

2010/04/10(土) 10:56:05

>>143
しなくていいでしょ

0146デフォルトの名無しさん

2010/04/10(土) 10:58:34

>>141
>>136でまぁあってるけど、あくまでも>>121。

0147デフォルトの名無しさん

2010/04/10(土) 11:07:51

>>136
http://www.horse-water.mydns.jp/tips/tips_P00015.html

0148136

2010/04/10(土) 11:11:35

>>146
121でいってることもわかるし、自分もそうあるべきだとおもうんだけど、TDD(JUnit)は対象のメソッドがpublicじゃないとテストを書くことすらできないわけだけど、そこに歯痒さや矛盾を感じない？

テストのために対象のコードを捻じ曲げる(publicにする、packageに入れる)とか、privateをテストできる別のツールに変えるとか、そういうことじゃそもそも本末転倒だと思うし。

0149デフォルトの名無しさん

2010/04/10(土) 11:15:23

>>143
JUnitとかCppUnitの解説本じゃないしね。
ちなみに、JavaだけじゃなくてC#とかもprivateメソッドを呼び出せる。
C++は知らない。

0150デフォルトの名無しさん

2010/04/10(土) 11:18:11

>>148
JUnit FAQすら読んでなかったのか

0151デフォルトの名無しさん

2010/04/10(土) 11:20:06

>>150
そんなの最初からわかってたでしょｗ

0152デフォルトの名無しさん

2010/04/10(土) 11:21:37

いやいやおまえら>>119の段階でそのレスしてやれよ

0153136

2010/04/10(土) 11:32:33

あれ、JUnitがしょぼいだけで、他のテストツールはprivateもテストできる(というかそれが当たり前)なの!?

なんか勝手にJUnitがTDDのデファクトスタンダードだと思い込んで、これでできないことは他でもできないと思ってた
すんませんでした

JUnit使うのやめて、もうちょっと他のツールを勉強してきます

0154デフォルトの名無しさん

2010/04/10(土) 11:43:54

とりあえず、ユニットテストとTDD　は切り離してかんがえたほうがいい。
TDDじゃなくてもユニットテストはやることだから。

0155デフォルトの名無しさん

2010/04/10(土) 20:06:57

>>148
>テストのために対象のコードを捻じ曲げる(publicにする、packageに入れる)とか、privateをテストできる別のツールに変えるとか、そういうことじゃそもそも本末転倒だと思うし。

それを本末転倒と思っちゃいけない。

コード書くときに、将来の保守性とか読みやすさとか、直接求められている仕様以外のことも考えて書くでしょ。
それと同じだと思えばいい。
テストできるってのは、それくらい大事なことなんだよ。

0156デフォルトの名無しさん

2010/04/10(土) 20:12:35

いや、本末転倒でしょ。
テスト容易性ってのはそういうこっちゃない。

0157デフォルトの名無しさん

2010/04/10(土) 20:46:47

微妙な問題だけど、教科書的に考えるなら、機能設計がきちんとできていれば、
public でないメソッドをテストする必要は基本的にはないはずなんだよね。
その必要が生じるということは、そのAPIでは機能が実現できないか、
テストを考える人間が機能の実装方法までテストしようとしている
（特定の実装に依存して機能を解釈している）ってことで、
とにかく、設計に問題なんらかの問題があるということじゃないの。

0158デフォルトの名無しさん

2010/04/10(土) 21:06:20

テストのためならprivateをpublicにするのも吝かではないっていう奴は、
某スレで、単体テストではprivateメンバの内容まで確認する必要がある
からステップ実行以外に手段はないって言ってた奴と同じにおいがする。

0159デフォルトの名無しさん

2010/04/10(土) 21:37:04

モジュールの外部設計レベルで振る舞いを確認するって事は本質的に
ブラックボックステストなわけだ。
テストのためのインタフェースを新たに公開するなんてのは根本的に話が
おかしい。

0160デフォルトの名無しさん

2010/04/10(土) 23:11:20

先週立ち読みしたBeautiful Codeにbinary searchの話が出てたけど、
あれはテストしにくい (head + tail) / 2 の部分だけをメソッドに切り出してテストしてたな。
これでテストできたことになんのか微妙だなとか思いながらよんでた。
最近だとメモリ増えてるからbyte配列ぐらいなら
head + tail がオーバーフローするぐらい確保できるかもしれんけど、
int配列とか参照型の配列だとちょっとな。

後付でテストするときにテストのために元のコード書き換える例って事で。

0161デフォルトの名無しさん

2010/04/11(日) 01:11:40

そんなにpublicが嫌なら、Java限定だが、
デフォルトのパッケージプライベートスコープで宣言すればいいじゃない。
パッケージ外には公開しないから、使う側としては無いのと一緒でしょ。

0162デフォルトの名無しさん

2010/04/11(日) 08:27:57

>>160
まあ最終的に、そういうアルゴリズム寄りの問題や、
パフォーマンスやメモリ効率なんかのクリティカルな問題を
扱う場合は、そういうことせざるを得ないよね。
自分は、要素技術の開発においては、そういうのはアリだと思う。

逆に言うと、アプリケーションの開発で、そういうことをする必要が出てくるというのは、
確立してないない要素技術を使おうとしている、ということで、
プロジェクト管理的にはリスク要因なんだよね。

そういう要素技術とアプリケーションの切り分けのような話は
テストの本にはあんまりでてこないから、
人によって、どこまでどうやって書いてあることをあてはめようとするかで、
いろいろと齟齬が生じるような気がする。

0163デフォルトの名無しさん

2010/04/11(日) 09:50:40

で、GUIやらDB絡みやらの単体テストはどうすればいいですかね

0164デフォルトの名無しさん

2010/04/11(日) 11:32:14

DB絡みのコードのテストは、JavaならDBUnitで決まりだな。.NETならndbunitがいけそう。
Railsのfixtureはイラネ。
GUIのテストはあんまりしないな。昔調べた限りでは、.NETのNUnitFormがそこそこ使えそうだった

0165デフォルトの名無しさん

2010/05/02(日) 17:56:02

TestCompleteって誰か使ってる？

0166デフォルトの名無しさん

2010/07/07(水) 13:32:23

テストを書きたいとおもっておりますが、
対象クラスの書き方について悩んでおります。

数学的な函数のように、Aを引数として呼べば、
必ずBが帰るというようなメソッドの作りでなくては
テストは書けないのでしょうか？

また、対象オブジェクトの状態を変更するして戻り値を返さないメソッドや、
メソッド内で対象オブジェクトのメンバ変数を利用しているものは、
テストしようにも出来ないのではないのでしょうか・・・。

後者に関してはメソッドに必要な情報を全て引数として渡すように変更し、
メンバ変数を内部で暗黙的に使用しないなの変更でよいのでしょうか・・・。

またその場合は隠蔽したいメンバ変数はどうしたらよいのか。

どの様にクラスを設計してよいかわかりません。

0167デフォルトの名無しさん

2010/07/07(水) 16:54:33

>>166
> また、対象オブジェクトの状態を変更するして戻り値を返さないメソッドや、
メソッド呼び出しした後に対象オブジェクトの状態をチェックすりゃいいだけでは？

0168デフォルトの名無しさん

2010/07/07(水) 16:59:48

>>167
ってことは、該当オブジェクトに内部の状態をテストするメソッドを書くことになるのかな？
クラスがテストでもりもり大きくなるのはどうなのかな？

0169デフォルトの名無しさん

2010/07/07(水) 17:24:26

>>168
外部にテスト用クラス作ってそこに書けばいいじゃないか。

0170デフォルトの名無しさん

2010/07/07(水) 17:27:30

>>169
内部の状態をテストするためのメソッドを外部のクラスに書けるの？

0171デフォルトの名無しさん

2010/07/07(水) 17:42:33

>>170
素直に公開すればいいじゃないか。

0172デフォルトの名無しさん

2010/07/07(水) 17:51:51

>>166
とりあえず『レガシーコード改善ガイド』読んでから出直して

0173デフォルトの名無しさん

2010/07/08(木) 23:53:37

>>166
普通、ユニットテストと言えば、パブリックなメンバのみにアクセスしてテストを書く。
オブジェクトの内部状態を変更するメソッドを呼び出した後、その内部状態に依存する
メソッドを呼び出して結果が意図通りか確認する。
例が悪いけど、setterで値をセットした後、getterで同じ値が帰ってくることを確認するみたいな感じ。
この場合、内部状態を変更するだけのメソッドや結果が内部状態に依存するメソッドを
それぞれ単独でテストすることはできない。

内部状態の変更を直接確認したければ、.NETとかJAVAならReflectionを使うことで
対象クラスのコードを変更しなくてもプライベートなメンバにアクセスできる。
Reflectionの面倒なコーディングをしなくてもプライベートなメンバにアクセスできる
テストツールもある。
この場合、内部状態を変更するだけのメソッドや結果が内部状態に依存するメソッドを
それぞれ単独でテストすることもできる。

前者はクラスの外部設計を検証していることになり、
後者はクラスの内部設計を検証していることになる。

こんな感じで合ってます？

『レガシーコード改善ガイド』は読みたいと思ってるんだけど、もっといいこと書いてるの？

0174デフォルトの名無しさん

2010/07/09(金) 12:50:55

>>173
> 『レガシーコード改善ガイド』は読みたいと思ってるんだけど、もっといいこと書いてるの？

ﾄﾞ素人のお前の稚拙な考察未満だとでも？

0175デフォルトの名無しさん

2010/07/09(金) 14:00:15

そもそも外部に一切の変更を与えないメソッドをpublicにする意味があるんだろうか

0176デフォルトの名無しさん

2010/07/09(金) 23:08:15

訂正します。
誤：『レガシーコード改善ガイド』は読みたいと思ってるんだけど、もっといいこと書いてるの？
正：『レガシーコード改善ガイド』は是非読みたい。きっともっといいこと書いてるに違いない。

0177デフォルトの名無しさん

2010/07/21(水) 05:14:25

このへんでも読んでみたら

翻訳書「レガシーコード改善ガイド」の注目トピック：CodeZine（コードジン）
http://codezine.jp/article/corner/308

0178デフォルトの名無しさん

2010/08/10(火) 16:04:37

テストってどうやって書くの？

引数Aのファイルを開いて引数Bの文字列を書く
みたいな関数があったとき、そのテストってのは
AのファイルにBが書かれているかをチェックする
ってこと？そういうコードを書けってこと？

0179デフォルトの名無しさん

2010/08/10(火) 16:51:37

うん。

0180デフォルトの名無しさん

2010/08/10(火) 20:18:32

ひゃーマジか。面倒くさいなー。
テストコードってテストしたいプログラムと同じ言語である必要は
無いよね？

0181デフォルトの名無しさん

2010/08/10(火) 20:24:15

ない。

0182デフォルトの名無しさん

2010/08/11(水) 20:55:36

理論上はないけれども関数・クラス・言語の構造などの関係で同一言語のほうが楽

C++でユーザープログラム書くときCのコンポーネント使うのに（存在すれば）ラッパークラス通すと楽なのに近い

0183デフォルトの名無しさん

2010/08/11(水) 23:21:38

>>178
> テストってどうやって書くの？
テストベッドがあって、そこにS式を放り込むと、そのS式を評価する関数が生成されて、
帰来する結果を書けばOKのはずなんだが > 少なくとも lisp 周辺では

0184デフォルトの名無しさん

2010/08/12(木) 18:56:18

>>183
たとえば戻り値が無い関数はどうするの？
引数を加工してファイルに書く関数とか

0185デフォルトの名無しさん

2010/08/13(金) 07:11:54

書いたファイルを読むんジャマイカ

0186デフォルトの名無しさん

2010/08/15(日) 01:07:16

GUIのテストとデータベース操作のテストはどういうツール使ってる？

0187デフォルトの名無しさん

2010/09/05(日) 10:21:51

test

0188デフォルトの名無しさん

2010/09/19(日) 21:28:26

別スレ立てた
ツール以外の話は移動よろ

【TDD】テスト駆動開発【TestFirst】
http://hibari.2ch.net/test/read.cgi/tech/1284899172/

0189デフォルトの名無しさん

2010/09/20(月) 22:52:34

webのテストツールでお勧めないか
seleniumは使ったことあるけど、多重フレームのせいか
コードのせいなのかはわからんがｗ、まともには動いてくれなかった

0190デフォルトの名無しさん

2010/09/30(木) 22:09:14

テスト

0191天使 ◆uL5esZLBSE

2011/07/04(月) 10:05:19.73

>>190

お前たちは本当にゴミだな

0192天使 ◆uL5esZLBSE

2011/07/04(月) 20:55:36.39

-----
＞＞＞＞＞＞＞＞たとえば戻り値が無い関数はどうするの？＜＜＜＜＜＜＜＜(キリッ!!!キリッッ！キリッッッッ！！！キリッ！！！！キリッッッッ!!!
---
＞＞＞＞＞引数を加工してファイルに書く関数とか＜＜＜＜＜(キリッッッ！！！キリッッ！！キリッッッ！キリッ!!!!
---------(キリッッ!!キリッキリッッ!

0193デフォルトの名無しさん

2011/08/29(月) 08:45:56.92

組み込みCでモック使った関数単体テストがしたいんだけど、cmockとcmockrayとならどちらが使いやすいんだろうか。

0194デフォルトの名無しさん

2011/09/02(金) 11:06:16.36

ttp://opencv.jp/googletestdocs/primer.html#primer-string-comparison
Google Testのドキュメントの文字列の比較のところに

> より詳細な文字列比較の方法（例えば，部分文字列，接頭語，接尾語，正規表現一致など）については，上級ガイドを参照してください．

とありましたので、てっきり「正規表現を使った文字列の比較」を行えると思ったのですが、
上級ガイドにその方法が書かれておりません。
念の為gtest-1.6.0のソースコードをあたってみましたが、こちらでも見つかりませんでした。

Google Testで正規表現を使った文字列の比較を行う方法はありますでしょうか？
もしくはPOSIX regexなど外部の正規表現ライブラリを使う必要がありますでしょうか？

0195 忍法帖【Lv=10,xxxPT】

2011/10/25(火) 07:44:15.12

テスト

0196 忍法帖【Lv=2,xxxP】

2011/10/30(日) 10:46:27.50

0197デフォルトの名無しさん

2011/10/31(月) 12:54:04.33

test

0198デフォルトの名無しさん

2011/10/31(月) 18:20:07.29

>>197
Failed
Success:3 Failure:121 Skip:0

0199デフォルトの名無しさん

2011/11/01(火) 02:48:40.64

>>198
死にたくなるなw

0200デフォルトの名無しさん

2011/11/01(火) 14:49:06.24

>>198
テストの数が少なすぎだろ

0201デフォルトの名無しさん

2011/11/22(火) 15:32:42.49

じゃあテスト

0202デフォルトの名無しさん

2011/11/23(水) 18:13:11.74

自作のテストツールにどんな名前をつければいいか困ってる。
いいアイデアぷりーず

0203デフォルトの名無しさん

2011/11/23(水) 21:54:31.93

TENGA

0204デフォルトの名無しさん

2011/11/24(木) 10:37:49.90

>>203
どういう意味？

0205デフォルトの名無しさん

2011/11/24(木) 11:35:20.77

ググれ

0206デフォルトの名無しさん

2011/11/25(金) 01:06:01.02

>>203はきっと自分では面白いと思ったのだろう。かわいそうに。

0207デフォルトの名無しさん

2012/06/22(金) 09:55:04.03

「Rational テスト仮想化／自動化ソリューション」
テスト期間10日が10分に！日本IBMが仮想テスト環境ツール 2012年06月22日 06時00分更新
ttp://ascii.jp/elem/000/000/703/703943/
　6月21日、日本IBMは仮想的なテスト環境を自動構築するソリューション
「Rational テスト仮想化／自動化ソリューション」を発表した。

　Rational テスト仮想化／自動化ソリューションは、テスト対象となるシステムへの入出力を
仮想的かつ自動的に再現する機能を持つ。これにより、テスト対象システムと接続するシステムの
完成を待ったり、稼働を停止する必要がなくなり、テスト環境を実際に構築することなく接続テストを
実施できる。結果として、テスト時間の短縮やテスト環境構築への投資と手間の削減が実現する。
　また、仮想化環境での接続テストが可能になることで、システム開発工程の早い段階で
不具合の修正ができるため、開発の最終段階での大幅な変更や品質問題発覚による開発遅延の
低減が可能となり、顧客へのサービス開始の遅れや追加コストの発生を防ぐとしている。
　たとえば、海外の金融機関では、テストの大部分を自動化できたことで、手作業による
テスト期間を10日から10分に削減したという。また、ある製造企業は、従来6カ月かかっていた
システム構築を2カ月短縮し、4カ月で完成させたとしている。
　IBM Rational テスト仮想化／自動化ソリューションの使用料金は、4000万円（100PVU）から。

■ このスレッドは過去ログ倉庫に格納されています