【TDD】テスト駆動開発【TestFirst】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/19(日) 21:26:12ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
0002デフォルトの名無しさん
2010/09/19(日) 21:46:07よろしければTDD入門によいWABサイトや、
書籍などの紹介を頼みます。
0003デフォルトの名無しさん
2010/09/19(日) 21:49:44作りながら考えるPGが多すぎる。かくいう俺もそうだけどｗ
フレームワークが出来た後なら余裕だけど、
フレームワークを作ってる最中は作業に水を差されてるみたいでなんか辛い。
0004デフォルトの名無しさん
2010/09/19(日) 22:22:46フレームワークありきでTDDは効果出るよね。
フレームワークもある程度固まったらテスト書かないとふあんだけど。
ドラフト状態部分のフレームワーク部分はテストを後に回してもいいキガス。
てか設計に掛けられる時間が少なかったり、
複数人で設計をレビューしながらまとめる文化がないよね。
0005デフォルトの名無しさん
2010/09/19(日) 23:05:170006デフォルトの名無しさん
2010/09/19(日) 23:48:40作りながら考えるからこそ
テストファーストになるんじゃないのか？
0007デフォルトの名無しさん
2010/09/20(月) 01:28:15名前なんていうのか忘れたけど
DDDだっけ？HDDだっけ？
0008デフォルトの名無しさん
2010/09/20(月) 01:35:38HDD: ハードディスクドライブ
0009デフォルトの名無しさん
2010/09/20(月) 02:18:410010デフォルトの名無しさん
2010/09/20(月) 08:17:43どうすれば楽しくなるのかな
0011デフォルトの名無しさん
2010/09/20(月) 10:22:31関数書き始めたとき、その関数がどんな時にエラーを返すか
詳細に検討してないことは、ままあるな。
先に考えるのメンドクセ。
0012デフォルトの名無しさん
2010/09/20(月) 14:18:37↓
以下は参考サイトのまとめ
○基本
[link]テスト駆動開発とPDCAサイクル - 開発者がテスト駆動開発をすると、生産性が上がる理由
[link]@IT - 「テスト駆動開発」はプログラマのストレスを軽減するか？
[link]テスト駆動開発やユニットテストを定着させるには
○実践
実際の開発では、すべてのコードに対してテストコードを書くなんてのは不可能。
どのコードに対してテストコードを書くと効果的か（価値があるか）、その判断基準の参考になる。
[link]リファクタリングとテストの関係(PDF)
0013デフォルトの名無しさん
2010/09/20(月) 21:56:28ttp://www.oreilly.co.jp/catalog/soon.html
ビューティフルテスティング 978-4-87311-474-3 \\\\3,360 2010年10月
0014デフォルトの名無しさん
2010/09/20(月) 23:44:18スレタイにBDDもいれろ
0015デフォルトの名無しさん
2010/09/20(月) 23:46:06webアプリ作る時ってプロトタイプを3日間とかもしくは2時間ぐらいで
モックとともにガゥーーーっと作るじゃん？
そういうのっていちいちBDDなんかで振る舞いや仕様を定義して・・・とかやってると
とてもじゃないが時間かかりすぎるんだけどどうしてるの？
0016デフォルトの名無しさん
2010/09/20(月) 23:49:350017デフォルトの名無しさん
2010/09/21(火) 01:10:31ダメなの？
0018デフォルトの名無しさん
2010/09/21(火) 01:33:37捨てるプロトタイプと、コア実装としてのプロトタイプが
あるとは思うけど、後者はちゃんと設計して作るもんだ。
説明用に2時間で作ったもんは捨てれ。
0019デフォルトの名無しさん
2010/09/21(火) 06:55:26が、趣味でも大型の変更は一回作って傾向見て捨てて
その経験だけ頭に入れて別途作り直したほうが結局は早いな
1回目のコードを大事にしようとすると歪が溜まるのは同じ
0020デフォルトの名無しさん
2010/09/21(火) 09:53:020021デフォルトの名無しさん
2010/10/11(月) 20:33:31全関数をテストするわけじゃなく、ある程度の単位でまとめて、そこで外部とのI/F決める。
その単位でのテストが目的で、普通は仮にでもそこを決めてから、コーディング始めるだろ。
じゃなかったら複数人での開発なんかできないぞ。
0022デフォルトの名無しさん
2010/10/12(火) 07:07:20テスト駆動開発やテストファーストの「テスト」という単語が勘違いされてるからな
そのために、振る舞い駆動開発などというものもでてきているんじゃないのか？
ようするに
「あれは(お前らが考えてる)テストじゃないんだ。振る舞いを定義してるんだ」
なんて
0023デフォルトの名無しさん
2010/12/22(水) 04:02:54とりあえず実装完了を示すテストだといってみたらどうだろう
0024デフォルトの名無しさん
2010/12/22(水) 07:01:25構成することを規約化したらエクセルドキュメントから
テストコードを自動生成できないかな
モックとテストファーストが満たせないか
0025デフォルトの名無しさん
2010/12/22(水) 20:20:050026デフォルトの名無しさん
2010/12/23(木) 10:05:36Cucumberみたいな自然言語使う流れもあるけど、あれは誰に見せるものなんだよw
0027デフォルトの名無しさん
2010/12/23(木) 14:23:432.テストコード
3.実装
でしょ？
テストコード書いてテストケース生成するのはまずいのでは？
0028デフォルトの名無しさん
2010/12/23(木) 20:43:311週間で作るとか1ヶ月とかのプロジェクトだとドキュメントなんて作ってられん
0029デフォルトの名無しさん
2010/12/24(金) 01:55:26カウボーイ・コーディングのアジャイルでしょ
アジャイルに関する実際の需要はそっちだったりする？ｗ
0030デフォルトの名無しさん
2010/12/24(金) 06:57:250031デフォルトの名無しさん
2010/12/25(土) 14:32:58テストコード側が最悪に書きにくくなりそうだ
振る舞いのフローチャート化も本当に単純なことしかできそうにない
ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38
0032デフォルトの名無しさん
2010/12/25(土) 14:52:11Javaだったらすでにそういうツールありそうだな
0033デフォルトの名無しさん
2010/12/25(土) 16:20:19立ち上げてみようかな。フローチャート図吐き出す案が思いついたら
0034デフォルトの名無しさん
2010/12/25(土) 17:43:00JDaveにHTML reportってのは有る。
003531
2010/12/27(月) 07:16:40シーケンス図っぽくしたら良いのだろうか
0036デフォルトの名無しさん
2010/12/27(月) 10:19:51ぐらいの短いサイクルだけで十分
0037デフォルトの名無しさん
2010/12/27(月) 11:42:33早う日本語で専門書だせー-
0038デフォルトの名無しさん
2011/01/17(月) 05:52:00聞いたことがあるけど
粒度の低いクラスから作っていく印象があるTDDはどうなのよ
0039デフォルトの名無しさん
2011/01/22(土) 20:49:540040デフォルトの名無しさん
2011/01/23(日) 20:54:270041デフォルトの名無しさん
2011/02/05(土) 08:30:07久しぶりにあさってみるか
0042デフォルトの名無しさん
2011/02/05(土) 12:02:06>>12の@ITの記事を参考にやってみたけどどうもシックリこないので…
・まずテストを書いて…ってどこから書くの？
・テストを書くのは関数単位？クラス単位？外部I/Fのみ？
外部I/Fのみが一番正しそうだけど、その場合別途ユニットテストも書くの?
内部が複雑な場合くっつけた状態でモレなくテストするのって難しいのでは？
・どこまで書いたら終わり？できたコードをみると引数チェックのヌケモレとかチラホラと
細かく回すメリットは理解できるのですがやってみると
品質も実装効率もガタ落ちなのでなにか根本的に間違えてそうな気がします。
0043デフォルトの名無しさん
2011/02/07(月) 11:01:02隣の芝生が青いだけでしょ
0044デフォルトの名無しさん
2011/02/07(月) 11:10:00品質が落ちるってのは…
新しい事に手を出すのは、余裕のある時の方がいいと思うよ
0045デフォルトの名無しさん
2011/02/07(月) 19:25:39TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの？
0046デフォルトの名無しさん
2011/02/07(月) 20:12:43UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い（結果を生む）かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと（異常なパラメータを渡したときの振る舞い）が予期した結果を生成するかチェックする
それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ
0047デフォルトの名無しさん
2011/02/07(月) 23:32:23すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。
0048デフォルトの名無しさん
2011/02/08(火) 07:48:30javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もＴＤＤツールにはあるのかな？
0049デフォルトの名無しさん
2011/02/08(火) 08:40:12他の言語はよく知らないけど、Pythonだとsys.stdoutを一時的に別のオブジェクトにすればprint文の出力結果を横取りできる。
import sys
from StringIO import StringIO
# 標準入出力オブジェクトをバックアップ
stdin_bkup = sys.stdin
stdout_bkup = sys.stdout
try:
# 標準入出力オブジェクトをStringIOで置き換える
sys.stdin = StringIO('dummy input text')
sys.stdout = StringIO()
# print文を使ったコード
print("Hello")
# StringIOから値を取り出して、expectedと比較する
expected = "Hello¥n"
output = sys.stdout.getvalue()
self.assertEqual(output, expected)
finally:
# 標準入出力オブジェクトをもとに戻す
sys.stdin = stdin_bkup
sys.stdout = stdout_bkup
Rubyならたしか$stdinと$stdoutを同じように置き換えればいい。
JavaもSystem.outを置き換えればいいんじゃないかな。
0050デフォルトの名無しさん
2011/02/09(水) 00:44:31テストしにくい、つまり設計がよくないということがテストできた
0051デフォルトの名無しさん
2011/02/09(水) 00:46:33うろ覚えだがこんな感じ
ByteArrayOutputStream out = new ByteArrayOutputStream();
System.setOut(new PrintWriter(out));
//テスト実行
String text = new String(out.getBytes());
assertThat(text, is("baw"));
0052デフォルトの名無しさん
2011/02/09(水) 15:18:100053デフォルトの名無しさん
2011/02/09(水) 19:19:09その内容を処理する部分に分けて設計し個別にテスト。
0054デフォルトの名無しさん
2011/02/09(水) 21:02:090055デフォルトの名無しさん
2011/02/15(火) 14:58:24リファクタリングも含めて
この辺りの誤解が未だにあるような気がする
0056デフォルトの名無しさん
2011/02/15(火) 15:45:51分けて作ったらどうダメなん？
0057デフォルトの名無しさん
2011/02/15(火) 15:49:580058デフォルトの名無しさん
2011/02/17(木) 07:40:15メモリが少ない環境だと、ストリームから逐一取り出してゴニョゴニョしたいときもあるだろうし
0059デフォルトの名無しさん
2011/02/17(木) 08:07:110060デフォルトの名無しさん
2011/02/17(木) 08:10:58「ファイルを取得して目的の形式で返す」までが単一の機能だろう
0061デフォルトの名無しさん
2011/02/17(木) 08:25:07Rubyだと、なんかよくわからん細かさのメソッドが（ユーザーから隠されて）存在するほうが喜ばれる気がする
オープンクラス利用して手元で動作修正することがしばしば行われるので、クラスやメソッドがどでんと大きいと面倒
0062デフォルトの名無しさん
2011/02/17(木) 10:34:31ん？それが分けるってことじゃ？
①ストリームオープン
②-1 ストリームから一行取得して目的の形式で返す
②-2 目的の形式のデータをごにょごにょ処理して何かをアウトプット
③データがなくなるまでループ
0063デフォルトの名無しさん
2011/02/17(木) 12:11:39>「ファイルを取得して目的の形式で返す」までが単一の機能だろう
要求されているのが単一の機能だとしても、それを複数に分けてはいけないと
いうルールはない。
分けた方がテストしやすいのなら、分けるべきだろう。
0064デフォルトの名無しさん
2011/02/17(木) 12:47:220065デフォルトの名無しさん
2011/02/18(金) 00:37:330066デフォルトの名無しさん
2011/02/19(土) 12:18:19その辺のサジ加減がわからん
0067デフォルトの名無しさん
2011/02/19(土) 12:55:17これで大丈夫と思ったらテストなんて書かなくて正解
あーこんなときどうするんだろって不安に思ったらテスト書く
0068デフォルトの名無しさん
2011/02/19(土) 13:28:24TDD的に
0069デフォルトの名無しさん
2011/02/19(土) 15:22:27○不安が出ないように事前にテストを書く。
0070デフォルトの名無しさん
2011/02/20(日) 00:51:21.25http://kakutani.com/20080216.html#p01
0071 忍法帖【Lv=1,xxxP】
2011/05/11(水) 10:31:59.120072デフォルトの名無しさん
2011/06/14(火) 11:09:22.79ひとによってはsetUp()/tearDown()のことをフィクスチャといっているんだけど、どうなん？
0073デフォルトの名無しさん
2011/06/14(火) 20:35:50.80http://www.metabolics.co.jp/XP/cppunit-doc/cookbook.htm
>テストコードにおいて、ある状態にオブジェクトを設定するためのコードを、テストの「フィクスチャ（土台）」と呼びます。
http://d.hatena.ne.jp/asakichy/20100405/1270437389
らしいから
>setUp()/tearDown()のことをフィクスチャといっている
でも問題なさそう
0074デフォルトの名無しさん
2011/06/15(水) 10:29:49.070075デフォルトの名無しさん
2011/06/15(水) 13:18:41.30ttp://ja.wikipedia.org/wiki/XUnit
> テストフィクスチャ
> テストを実行、成功させるために必要な状態や前提条件の集合を、フィクスチャと呼ぶ。
> これらはテストコンテキストとも呼ばれる。
> 開発者はテストの実行前にテストに適した状態を整え、テスト実行後に元の状態を復元することが望ましい。
これじゃ何のことか分かりにくいなあ。
0076デフォルトの名無しさん
2011/06/15(水) 18:50:16.06初学の人がこれ読んだだけじゃチンプンカンプンだろう
0077デフォルトの名無しさん
2011/06/18(土) 23:25:11.37これで充分わかるだろ
0078デフォルトの名無しさん
2011/06/22(水) 14:42:58.40例えばRailsだとテストデータをyamlで用意する手段があって、それをフィクスチャと呼んでる。
基本的にはテストするために用意するテストデータやオブジェクトのことだと思っておけば大丈夫。
0079デフォルトの名無しさん
2011/06/22(水) 16:09:43.38ちがうよ
0080デフォルトの名無しさん
2011/06/22(水) 16:36:00.05テストの為のお膳立てじゃね？
0081デフォルトの名無しさん
2011/06/22(水) 17:15:39.89なにが違うか説明してくれよ
0082デフォルトの名無しさん
2011/06/22(水) 17:32:04.400083デフォルトの名無しさん
2011/06/22(水) 17:42:11.76テスト用のデータなのか、テスト用のプログラムなのかって違い
0084デフォルトの名無しさん
2011/06/27(月) 14:42:18.250085デフォルトの名無しさん
2011/06/27(月) 15:01:59.49開発者としてどうよ
0086デフォルトの名無しさん
2011/06/27(月) 15:20:10.96data =
0087デフォルトの名無しさん
2011/07/02(土) 00:38:39.150088デフォルトの名無しさん
2011/07/04(月) 17:02:36.680089デフォルトの名無しさん
2011/07/04(月) 21:57:39.910090デフォルトの名無しさん
2011/07/05(火) 11:28:38.99それは実践が伴ってるという意味？
別に全部見てるわけじゃ無いけど、最近TDDでプログラミングとかバリバリしてるようには見えない。
実践が伴わなければ本とか記事とか書くなと言うわけじゃ無いんだが、どうもうさんくさい。
0091デフォルトの名無しさん
2011/07/05(火) 17:09:05.740092デフォルトの名無しさん
2011/07/06(水) 20:26:40.58そんな事実みたことねーよ。
0093デフォルトの名無しさん
2011/07/06(水) 20:36:51.52うち元請けじゃないし
0094デフォルトの名無しさん
2011/07/13(水) 00:20:56.20t_wadaは下心。
Twitterで流れていたネタｗ
0095デフォルトの名無しさん
2011/07/13(水) 17:00:39.07古いね。
0096デフォルトの名無しさん
2011/07/14(木) 08:02:22.700097デフォルトの名無しさん
2011/07/14(木) 09:49:55.26ということで話題を投下。ちょっと新人にTDD教えるのにペアプロしようと思うんだがなにかいいお題はないかな。
言語はRubyで仕事はRailsだけど、とりあえずTDDについておしえたいのでWebアプリをお題にするのは避けようと思ってる。
定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。
0098デフォルトの名無しさん
2011/07/14(木) 11:22:03.40今までやってた業務のやつやらしゃいいじゃん
0099デフォルトの名無しさん
2011/07/14(木) 22:29:28.390100デフォルトの名無しさん
2011/07/15(金) 04:17:44.07適当に実業務の中でTDDを覚えたり2chやWebの記事やblogなどで勉強した感じですかね？
少なくともTDDBCとかには出ていない雰囲気がする。。。
0101デフォルトの名無しさん
2011/07/15(金) 12:53:11.73■ このスレッドは過去ログ倉庫に格納されています