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

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

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

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

　　　　　　　　　　　　　　完

前スレ >>996-997

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

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

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

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

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

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

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

　　　　　　　　　　　　　　完

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>17
>>11

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

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

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

typoしまくりすまん。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

kent beckがか？ｗ

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

語る前に本くらいは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どういうこと？

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

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

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

Seleniumの話題はここでおk？

テスターはツール扱い？

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

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

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

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

Test

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

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

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

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

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

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

板違い

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

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

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

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

>>45はコピペ

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

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

>>52
HTMLならあるよ。

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

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

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

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

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

立案書？ なんだそれ。

テスト全体計画立案

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

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

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

>>56 は、>>55 の

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

についてのレスだよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まずは仕様をageようか

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

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

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

まずは仕様をageようか

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

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

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

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

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

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

そうか

test

test

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

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

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

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

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

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

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

俺も今挑戦中。

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

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

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

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

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

>>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回)×２
にすべてなっているみたい

>>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:}

こっちの手元でも、「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ブラウザで開いて結果を見る)

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

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

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

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

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

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:}

なお、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;}

タイポしたので、やりなおし。
$ 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:}

タイポしたのでやり直し、その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         :   : }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はぁ？

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

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

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

ならねーよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>140
読んだ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TestCompleteって誰か使ってる？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

うん。

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

ない。

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

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

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

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

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

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

test

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

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

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

テスト

>>190


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

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

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

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

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

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

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

テスト

t

test

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

>>198
死にたくなるなw

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

じゃあテスト

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

TENGA

>>203
どういう意味？

ググれ

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

「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）から。