トップページ⇒tech
174コメント45KB

【TDD】テスト駆動開発【TestFirst】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/09/19(日) 21:26:12
テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/
0002デフォルトの名無しさん2010/09/19(日) 21:46:07
>>1
よろしければTDD入門によいWABサイトや、
書籍などの紹介を頼みます。
0003デフォルトの名無しさん2010/09/19(日) 21:49:44
日本人にテストファーストはなじまないと思うよ。
作りながら考えるPGが多すぎる。かくいう俺もそうだけどｗ

フレームワークが出来た後なら余裕だけど、
フレームワークを作ってる最中は作業に水を差されてるみたいでなんか辛い。
0004デフォルトの名無しさん2010/09/19(日) 22:22:46
プロトタイプ作ってる間はテストファーストはなあ。
フレームワークありきでTDDは効果出るよね。

フレームワークもある程度固まったらテスト書かないとふあんだけど。

ドラフト状態部分のフレームワーク部分はテストを後に回してもいいキガス。

てか設計に掛けられる時間が少なかったり、
複数人で設計をレビューしながらまとめる文化がないよね。
0005デフォルトの名無しさん2010/09/19(日) 23:05:17
ここは天才チンパンジーのアイちゃん（ｒｙ
0006デフォルトの名無しさん2010/09/19(日) 23:48:40
>>3
作りながら考えるからこそ
テストファーストになるんじゃないのか？
0007デフォルトの名無しさん2010/09/20(月) 01:28:15
最近TDDじゃなくてアレだよね
名前なんていうのか忘れたけど
DDDだっけ？HDDだっけ？
0008デフォルトの名無しさん2010/09/20(月) 01:35:38
DDD: GNUのGUIデバッガ
HDD: ハードディスクドライブ
0009デフォルトの名無しさん2010/09/20(月) 02:18:41
RDDのことか
0010デフォルトの名無しさん2010/09/20(月) 08:17:43
テストコードって書くの楽しくないからどうしても後回しにしたくなるんだよな
どうすれば楽しくなるのかな
0011デフォルトの名無しさん2010/09/20(月) 10:22:31
>>6
関数書き始めたとき、その関数がどんな時にエラーを返すか
詳細に検討してないことは、ままあるな。
先に考えるのメンドクセ。
0012デフォルトの名無しさん2010/09/20(月) 14:18:37
ググって見つかった最初のページに
↓

以下は参考サイトのまとめ

○基本

[link]テスト駆動開発とPDCAサイクル - 開発者がテスト駆動開発をすると、生産性が上がる理由
[link]@IT - 「テスト駆動開発」はプログラマのストレスを軽減するか？
[link]テスト駆動開発やユニットテストを定着させるには

○実践

実際の開発では、すべてのコードに対してテストコードを書くなんてのは不可能。
どのコードに対してテストコードを書くと効果的か（価値があるか）、その判断基準の参考になる。

[link]リファクタリングとテストの関係(PDF)
0013デフォルトの名無しさん2010/09/20(月) 21:56:28
オライリーのビューティフルシリーズってどうなの？

ttp://www.oreilly.co.jp/catalog/soon.html
ビューティフルテスティング 978-4-87311-474-3 \\\\3,360 2010年10月
0014デフォルトの名無しさん2010/09/20(月) 23:44:18
>>1
スレタイにBDDもいれろ
0015デフォルトの名無しさん2010/09/20(月) 23:46:06
それは置いておいて、
webアプリ作る時ってプロトタイプを3日間とかもしくは2時間ぐらいで
モックとともにガゥーーーっと作るじゃん？

そういうのっていちいちBDDなんかで振る舞いや仕様を定義して・・・とかやってると
とてもじゃないが時間かかりすぎるんだけどどうしてるの？
0016デフォルトの名無しさん2010/09/20(月) 23:49:35
おまえ、まさかプロトタイプを本番に使ってないよな？
0017デフォルトの名無しさん2010/09/21(火) 01:10:31
え、、、、


ダメなの？
0018デフォルトの名無しさん2010/09/21(火) 01:33:37
おまwww

捨てるプロトタイプと、コア実装としてのプロトタイプが
あるとは思うけど、後者はちゃんと設計して作るもんだ。

説明用に2時間で作ったもんは捨てれ。
0019デフォルトの名無しさん2010/09/21(火) 06:55:26
趣味なのか仕事なのかでも違うと思う

が、趣味でも大型の変更は一回作って傾向見て捨てて
その経験だけ頭に入れて別途作り直したほうが結局は早いな
1回目のコードを大事にしようとすると歪が溜まるのは同じ
0020デフォルトの名無しさん2010/09/21(火) 09:53:02
プロトタイプを実践で使いたいなら導入時にテストをかいておきたいなあ。
0021デフォルトの名無しさん2010/10/11(月) 20:33:31
なんかテスト駆動開発を勘違いしている奴多くないか。
全関数をテストするわけじゃなく、ある程度の単位でまとめて、そこで外部とのI/F決める。
その単位でのテストが目的で、普通は仮にでもそこを決めてから、コーディング始めるだろ。
じゃなかったら複数人での開発なんかできないぞ。
0022デフォルトの名無しさん2010/10/12(火) 07:07:20
>>21
テスト駆動開発やテストファーストの「テスト」という単語が勘違いされてるからな
そのために、振る舞い駆動開発などというものもでてきているんじゃないのか？
ようするに

　「あれは(お前らが考えてる)テストじゃないんだ。振る舞いを定義してるんだ」

なんて
0023デフォルトの名無しさん2010/12/22(水) 04:02:54
設計や実装の不具合がないことを示すテストじゃなくて
とりあえず実装完了を示すテストだといってみたらどうだろう
0024デフォルトの名無しさん2010/12/22(水) 07:01:25
プリミティブ、配列、ツリーだけでインプットとアウトプットを
構成することを規約化したらエクセルドキュメントから
テストコードを自動生成できないかな

モックとテストファーストが満たせないか
0025デフォルトの名無しさん2010/12/22(水) 20:20:05
テストコードからExcelファイルを自動生成すればよくね、Apache POI辺りを使って
0026デフォルトの名無しさん2010/12/23(木) 10:05:36
テストコードからExcel吐いたりしている人はいるらしい

Cucumberみたいな自然言語使う流れもあるけど、あれは誰に見せるものなんだよw
0027デフォルトの名無しさん2010/12/23(木) 14:23:43
1.テストケース（ドキュメント）
2.テストコード
3.実装

でしょ？

テストコード書いてテストケース生成するのはまずいのでは？
0028デフォルトの名無しさん2010/12/23(木) 20:43:31
テストコードがドキュメントみたいな開発スタイルもある
1週間で作るとか1ヶ月とかのプロジェクトだとドキュメントなんて作ってられん
0029デフォルトの名無しさん2010/12/24(金) 01:55:26
それは俗にいう誤ったＴＤＤ、
カウボーイ・コーディングのアジャイルでしょ

アジャイルに関する実際の需要はそっちだったりする？ｗ
0030デフォルトの名無しさん2010/12/24(金) 06:57:25
安易に「誤った」なんて言っちゃうマヌケw
0031デフォルトの名無しさん2010/12/25(土) 14:32:58
テストコードからHTML生成やってみようかと思ったが
テストコード側が最悪に書きにくくなりそうだ
振る舞いのフローチャート化も本当に単純なことしかできそうにない

ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38
0032デフォルトの名無しさん2010/12/25(土) 14:52:11
>>31
Javaだったらすでにそういうツールありそうだな

0033デフォルトの名無しさん2010/12/25(土) 16:20:19
日本語のソースフォージにはなさそうだったから
立ち上げてみようかな。フローチャート図吐き出す案が思いついたら
0034デフォルトの名無しさん2010/12/25(土) 17:43:00
>31
JDaveにHTML reportってのは有る。
0035312010/12/27(月) 07:16:40
垂直に上から下への一本線のフローチャートしかおもいつかないや
シーケンス図っぽくしたら良いのだろうか
0036デフォルトの名無しさん2010/12/27(月) 10:19:51
ユニットテストなら生成→値をセット・実行→値をゲット→検証
ぐらいの短いサイクルだけで十分
0037デフォルトの名無しさん2010/12/27(月) 11:42:33
RSpecの本まだー？
早う日本語で専門書だせー-
0038デフォルトの名無しさん2011/01/17(月) 05:52:00
粒度の高い結合テストしてから粒度の低い単体テストしないと無駄が多いって
聞いたことがあるけど

粒度の低いクラスから作っていく印象があるTDDはどうなのよ
0039デフォルトの名無しさん2011/01/22(土) 20:49:54
ネタがないね
0040デフォルトの名無しさん2011/01/23(日) 20:54:27
Twitterとかじゃ盛り上がっているようだな
0041デフォルトの名無しさん2011/02/05(土) 08:30:07
Fit: Framework for Integrated Test

久しぶりにあさってみるか
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:39
おいらはTDDやったことありませんが
TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの？
0046デフォルトの名無しさん2011/02/07(月) 20:12:43
>>42
UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い（結果を生む）かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと（異常なパラメータを渡したときの振る舞い）が予期した結果を生成するかチェックする

それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ
0047デフォルトの名無しさん2011/02/07(月) 23:32:23
>>42
すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。
0048デフォルトの名無しさん2011/02/08(火) 07:48:30
よくあるAnimal->Dog,Catなクラスのbark関数ってどうやってテストするの？
javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もＴＤＤツールにはあるのかな？
0049デフォルトの名無しさん2011/02/08(火) 08:40:12
>>48
他の言語はよく知らないけど、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
>>48
テストしにくい、つまり設計がよくないということがテストできた
0051デフォルトの名無しさん2011/02/09(水) 00:46:33
一応、Javaでも可能。
うろ覚えだがこんな感じ
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:10
csvとかファイル受け取って処理するコードのテストって、どうかくの？
0053デフォルトの名無しさん2011/02/09(水) 19:19:09
自分ならファイルを情報を取得する部分と
その内容を処理する部分に分けて設計し個別にテスト。
0054デフォルトの名無しさん2011/02/09(水) 21:02:09
えっ
0055デフォルトの名無しさん2011/02/15(火) 14:58:24
テスト可搬性高＝コード最適化じゃないからね
リファクタリングも含めて
この辺りの誤解が未だにあるような気がする
0056デフォルトの名無しさん2011/02/15(火) 15:45:51
>>53のケースへの適切な対処法を具体的に聞きたいな
分けて作ったらどうダメなん？
0057デフォルトの名無しさん2011/02/15(火) 15:49:58
むしろ分けずに書くのはドシロウトだろ
0058デフォルトの名無しさん2011/02/17(木) 07:40:15
まぁ環境によるわな
メモリが少ない環境だと、ストリームから逐一取り出してゴニョゴニョしたいときもあるだろうし
0059デフォルトの名無しさん2011/02/17(木) 08:07:11
それでもわけるだろ
0060デフォルトの名無しさん2011/02/17(木) 08:10:58
分けねえよ
「ファイルを取得して目的の形式で返す」までが単一の機能だろう
0061デフォルトの名無しさん2011/02/17(木) 08:25:07
言語によるかもしれん
Rubyだと、なんかよくわからん細かさのメソッドが（ユーザーから隠されて）存在するほうが喜ばれる気がする
オープンクラス利用して手元で動作修正することがしばしば行われるので、クラスやメソッドがどでんと大きいと面倒
0062デフォルトの名無しさん2011/02/17(木) 10:34:31
>>60
ん？それが分けるってことじゃ？
①ストリームオープン
　　②-1 ストリームから一行取得して目的の形式で返す
　　②-2 目的の形式のデータをごにょごにょ処理して何かをアウトプット
③データがなくなるまでループ
0063デフォルトの名無しさん2011/02/17(木) 12:11:39
>>60
>「ファイルを取得して目的の形式で返す」までが単一の機能だろう
要求されているのが単一の機能だとしても、それを複数に分けてはいけないと
いうルールはない。
分けた方がテストしやすいのなら、分けるべきだろう。
0064デフォルトの名無しさん2011/02/17(木) 12:47:22
四の五の言わずにソース貼れや
0065デフォルトの名無しさん2011/02/18(金) 00:37:33
大抵はreaderとhandlerにわける
0066デフォルトの名無しさん2011/02/19(土) 12:18:19
結局公開インターフェースだけテストすればいいのかな
その辺のサジ加減がわからん
0067デフォルトの名無しさん2011/02/19(土) 12:55:17
よく言われるのは自分の不安がなくなるまでかな
これで大丈夫と思ったらテストなんて書かなくて正解
あーこんなときどうするんだろって不安に思ったらテスト書く
0068デフォルトの名無しさん2011/02/19(土) 13:28:24
それはちょっと違くねえか
TDD的に
0069デフォルトの名無しさん2011/02/19(土) 15:22:27
×不安になったらテストを書く。
○不安が出ないように事前にテストを書く。
0070デフォルトの名無しさん2011/02/20(日) 00:51:21.25
角谷さんの記事が参考になった
http://kakutani.com/20080216.html#p01
0071 忍法帖【Lv=1,xxxP】 2011/05/11(水) 10:31:59.12
0072デフォルトの名無しさん2011/06/14(火) 11:09:22.79
フィクスチャって、テストデータのことだよね？違う？
ひとによってはsetUp()/tearDown()のことをフィクスチャといっているんだけど、どうなん？
0073デフォルトの名無しさん2011/06/14(火) 20:35:50.80
>フィクスチャとは、テスト・ケースのもととなるオブジェクトの集合です
http://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.07
むしろテストデータをフィクスチャとか、マジ素人
0075デフォルトの名無しさん2011/06/15(水) 13:18:41.30
Wikipediaに説明があった。
ttp://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
>>78
ちがうよ
0080デフォルトの名無しさん2011/06/22(水) 16:36:00.05
テストデータっていうよりか
テストの為のお膳立てじゃね？
0081デフォルトの名無しさん2011/06/22(水) 17:15:39.89
>>79
なにが違うか説明してくれよ
0082デフォルトの名無しさん2011/06/22(水) 17:32:04.40
コピーはゼロックスだがゼロックスはコピーとは限らないだろ
0083デフォルトの名無しさん2011/06/22(水) 17:42:11.76
そういう関係じゃないと思う
テスト用のデータなのか、テスト用のプログラムなのかって違い
0084デフォルトの名無しさん2011/06/27(月) 14:42:18.25
テストの前提となる環境データその他を指すんじゃねぇの
0085デフォルトの名無しさん2011/06/27(月) 15:01:59.49
何でもデータの一言で片付けるのは
開発者としてどうよ
0086デフォルトの名無しさん2011/06/27(月) 15:20:10.96
データなんだからデータでいいだろ
data =
0087デフォルトの名無しさん2011/07/02(土) 00:38:39.15
まあ、とりあえずTDDといったら、日本人ならt_wadaさんだな。
0088デフォルトの名無しさん2011/07/04(月) 17:02:36.68
t_wadaって実践が伴ってるんだろうか
0089デフォルトの名無しさん2011/07/04(月) 21:57:39.91
数年前にご一緒したことありますが、プラグマティックな方でしたよ
0090デフォルトの名無しさん2011/07/05(火) 11:28:38.99
>>89
それは実践が伴ってるという意味？
別に全部見てるわけじゃ無いけど、最近TDDでプログラミングとかバリバリしてるようには見えない。
実践が伴わなければ本とか記事とか書くなと言うわけじゃ無いんだが、どうもうさんくさい。
0091デフォルトの名無しさん2011/07/05(火) 17:09:05.74
だいたい名前が売れてる人は、実際には他人のコードなのに、そいつが書いたかのような事になっている。
0092デフォルトの名無しさん2011/07/06(水) 20:26:40.58
>>91
そんな事実みたことねーよ。
0093デフォルトの名無しさん2011/07/06(水) 20:36:51.52
ぶっちゃけ他社のソース見ることはないな
うち元請けじゃないし
0094デフォルトの名無しさん2011/07/13(水) 00:20:56.20
t-wadaは真心。
t_wadaは下心。
Twitterで流れていたネタｗ
0095デフォルトの名無しさん2011/07/13(水) 17:00:39.07
>>94
古いね。
0096デフォルトの名無しさん2011/07/14(木) 08:02:22.70
こんなしょーもないネタを事情通っぽく「古いね」とか言われてもなぁ。
0097デフォルトの名無しさん2011/07/14(木) 09:49:55.26
おまえらTDDについて話せよ。

ということで話題を投下。ちょっと新人にTDD教えるのにペアプロしようと思うんだがなにかいいお題はないかな。

言語はRubyで仕事はRailsだけど、とりあえずTDDについておしえたいのでWebアプリをお題にするのは避けようと思ってる。

定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。
0098デフォルトの名無しさん2011/07/14(木) 11:22:03.40
別に構えてお題を用意する必要ないだろ
今までやってた業務のやつやらしゃいいじゃん
0099デフォルトの名無しさん2011/07/14(木) 22:29:28.39
だよなあ
0100デフォルトの名無しさん2011/07/15(金) 04:17:44.07
ここにいる人ってTDDBCとか出たり、テスト駆動開発入門の本を読んだりしないで
適当に実業務の中でTDDを覚えたり2chやWebの記事やblogなどで勉強した感じですかね？
少なくともTDDBCとかには出ていない雰囲気がする。。。
0101デフォルトの名無しさん2011/07/15(金) 12:53:11.73
ヒント：今までのTDDBCの参加のべ人数を推定してみよう
0102デフォルトの名無しさん2011/07/16(土) 00:39:49.48
あんなイベント出てるやつは「TDDBCに参加することでTDDをなんとなく理解をしている自分に酔ってる」と思う。
まあ、2chの練習も程度が低いので五十歩百歩だなｗｗｗ
0103デフォルトの名無しさん2011/07/16(土) 00:40:56.78
ああいう、オフのイベントに参加できるだけリア充だと思う。
俺には考えられない。。。
0104デフォルトの名無しさん2011/07/16(土) 04:16:36.95
reviewで充分だよな
0105デフォルトの名無しさん2011/07/17(日) 22:35:19.81
>>102
入り口はそれでもいいんだよ
0106デフォルトの名無しさん2011/07/19(火) 17:32:31.53
bootcampに参加する奴って、人脈を広げたい奴か、自分で書籍を読み通すことができない奴か、
暇人かのどれかでしょ。
0107デフォルトの名無しさん2011/07/19(火) 18:57:09.08
どうした、bootcampで小馬鹿にでもされたか？
0108デフォルトの名無しさん2011/07/19(火) 19:23:10.60
TDDBCを叩いてる奴は和田さんに相手にしてもらえなくて悲しい思いでもしたのか？
0109デフォルトの名無しさん2011/07/19(火) 20:35:24.16
これは酷い
0110デフォルトの名無しさん2011/07/19(火) 21:19:32.09
TDDBC参加すらしたことのない小者が2chでTDD？ﾌﾟｹﾞﾗ。

とかいいながらそれは無いわ…。引くわ…。
0111デフォルトの名無しさん2011/07/20(水) 11:50:04.76
なんつーか、マ板でやれお前ら
0112デフォルトの名無しさん2011/07/20(水) 21:38:39.32
まずは、外に出て人に会うことから始めろよｗｗｗ
0113デフォルトの名無しさん2011/07/20(水) 21:54:26.24
堪忍して
0114デフォルトの名無しさん2011/07/28(木) 18:40:18.43
テストに関するオススメの良書教えて
0115デフォルトの名無しさん2011/07/28(木) 18:46:36.80
あげ
0116デフォルトの名無しさん2011/07/28(木) 21:01:34.98
良書はまだ無い、
原点のテスト駆動開発入門を写経するが吉


0117デフォルトの名無しさん2011/07/28(木) 21:21:52.42
テスト駆動開発入門は訳がひどいと書いてあるのが不安になるな
英語の勉強もかねて原著を読むか・・・

↓ここらへんの書籍ってどうなの？

基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ソフトウェアテスト293の鉄則
0118デフォルトの名無しさん2011/07/28(木) 21:47:37.60
本読んでTDDできると思ってるやつらおめでたすぎ。
TDDBCに参加しないと真のTDDは実践できない。
0119デフォルトの名無しさん2011/07/28(木) 22:09:02.48
釣りにすらなんねーだろ…ｗ
0120デフォルトの名無しさん2011/07/28(木) 22:09:20.82
宗教的で気持ち悪いな
0121デフォルトの名無しさん2011/07/28(木) 22:16:19.16
>117
テスト駆動開発入門は確かに読みにくいけど、コードを写経する分には問題ない
1回写経してみると読みにくさも気にならないと思う

ソフトウェア技法とかの本はどっちかというと、品質保証系のテストの本。
そっちはそっちで役に立つし、TDDに応用できないかと言えば色々できるけど、別の分野と考えた方がいいかも。
良書ではあると思うよ
0122デフォルトの名無しさん2011/07/28(木) 23:24:00.87
TDDは慣れるものじゃなくて、理解して実践する類のもの
写経なんかすんなよ　ケントベック泣いちゃうぞ

写経している奴は、ケントベックが
「他のTODOをやってみたが上手く行かないことが分かったので、先にこっちのTODOをやる」
などとさらっと書いてある部分はどうしてんだろう
0123デフォルトの名無しさん2011/07/29(金) 00:52:42.66
右も左も解らない状態でどうやって慣れるのさｗ
0124デフォルトの名無しさん2011/07/29(金) 20:43:51.15
テストって二つの意味があるんだよな。
設計をプログラムに落とすテスト駆動開発と。
品質を保証するテスト。

どっちもテストって名前ついているけど、
全くの別物だよ。
0125デフォルトの名無しさん2011/07/29(金) 22:55:13.75
そういうデベロッパーテスティングの意味を理解するだけでもTDDBCにいく意味はあると思うぞ。
0126デフォルトの名無しさん2011/07/31(日) 08:55:27.49
TDDについて語るスレなんだから、ここで語るんだよ。
TDDBCについて語るスレじゃねーぞｗ
0127デフォルトの名無しさん2011/08/01(月) 01:13:08.98
>117 読むなら
レガシーコード改善ガイド
+ パターン指向リファクタリング入門
で おｋ
補足資料として リファクタリング, テスト駆動開発入門 があればって感じだね
まぁ後、アジャイルソフトウェア開発の奥義, コードコンプリート なんかも気休めにはなるだろう。


"品質保証系のテスト"の話がしたいなら別だが。
0128デフォルトの名無しさん2011/08/02(火) 08:12:19.14
>>125
なんかもの凄く必死に見えるんだが、そんなにTDDBCの空席目立ったのか？
0129デフォルトの名無しさん2011/08/02(火) 15:00:00.36
ttp://d.hatena.ne.jp/absj31/20110731/1312209896
見たけど、なんでt-wadaがTDDのエバンジェリストっぽい立ち居地にいるのかわからん。
0130デフォルトの名無しさん2011/08/02(火) 15:25:14.87
>>129
優秀かつ積極的にTDDを広めようとした人が他にいなかったからじゃないか?
0131デフォルトの名無しさん2011/08/02(火) 22:30:09.48
いっつもt_yanoとごっちゃになる。
0132デフォルトの名無しさん2011/08/03(水) 01:26:15.74
>>129
じゃあ、あなたが立ち上がりましょう！大丈夫、あなたほど優秀な人ならば表の世界で活躍できる！
さあ、怖がらないで！
0133デフォルトの名無しさん2011/08/03(水) 18:16:09.36
>>127
ありがとう
その2つ読んでみます。
リファクタリングはちょうどオブジェクト指向の勉強として読んでいます

>>117と似たようなシリーズの「はじめて学ぶソフトウェアのテスト技法」がいつの間にか家にあったので
とりあえず読んでみようと想うのですが、>>117の3つって必要ですかね
なんか表紙が似ているので同じようなものだと嫌だなぁとｗ
0134デフォルトの名無しさん2011/08/04(木) 01:42:56.84
> 設計をプログラムに落とすテスト駆動開発
なんかニュアンス違うw

テスト駆動開発でプログラムができあがる、ってまさに設計しながらって感じで
テスト駆動開発の"前"に行う設計ってせいぜいおおまかな下書きラフスケッチみたいなものでしかない。
とてもじゃないがソースに落とせないよ
0135デフォルトの名無しさん2011/08/04(木) 02:26:35.10
みんな表に出て議論しようよ。
みなさんの知見をもとにより良い開発について考えていきましょう！
0136デフォルトの名無しさん2011/08/04(木) 21:43:36.36
個々の事例となると社外秘だったりするんで
公開の場でってのは難しいわなぁ
0137デフォルトの名無しさん2011/08/07(日) 10:18:32.85
BDDになるとどのくらい違うんだっけ？
イマイチ、TDDとの違いがピンと来ないんだが
0138デフォルトの名無しさん2011/08/07(日) 14:29:01.42
BDDはただの言い換えでしょ、Spec系の。
俺は嫌い。
0139デフォルトの名無しさん2011/08/07(日) 16:34:10.79
うむ
0140デフォルトの名無しさん2011/08/07(日) 16:41:55.68
結局BDDってなんだったの感はあるよな。
最近詳しく言及してたのは
ttp://ukstudio.jp/2011/07/02/bdd
ぐらいか?
0141デフォルトの名無しさん2011/08/07(日) 17:22:20.47
滝への回帰としか思えん
0142デフォルトの名無しさん2011/08/08(月) 01:29:11.62
和田さん入籍おめでとうございます。
0143デフォルトの名無しさん2011/08/08(月) 14:43:54.15
テスト駆動開発ってプログラミングを楽にするけど、
メインは、プログラマーの底上げを図るための物だよね。
だから力がある人や、それと同等の力のある人同士で
プロジェクトを作成する人には不要だね。
0144デフォルトの名無しさん2011/08/08(月) 15:31:50.53
力がある人もプログラミングを楽にできるのだが
0145デフォルトの名無しさん2011/08/08(月) 22:27:31.26
きしださんとか事あるごとにテストに懐疑的な発言してるけど、あの人が言うと業界にいい加減な人を増やすだけだからやめてほしい。

勉強熱心なのは認めるけど、それを解釈する脳ミソや、実践する態度に疑問を感じてならない。
0146デフォルトの名無しさん2011/08/09(火) 11:28:30.47
>>145
誰？
どこに何を発言したの？
見たこと無いけど。
0147デフォルトの名無しさん2011/08/10(水) 18:58:30.33
このへんか。もっと昔にも言ってたけどこの人発言量多いから探すの面倒だな。

TDDとか「TDDはあなたの心のなかにあります」みたいなあいまいな言葉なんだから、技術用語として使うのはどうかと思う。その言葉を使って意思疎通ができてない。混乱にしかならないので、この言葉ははやめに葬るほうがいい気がするよ。
https://twitter.com/#!/kis/status/100050996616642560
それもこれもケントベックというペテン師が悪い。
https://twitter.com/#!/kis/status/100051107589537792
0148デフォルトの名無しさん2011/08/10(水) 23:42:41.43
良いテストを構築できるかどうかがプログラマの腕の見せ所だろ？
0149デフォルトの名無しさん2011/08/11(木) 11:21:29.20
>>147
hatenaのページ見つけたけど、ことあるごとにテストに懐疑的な発言をしているとは見えないんだが。
googleでざっと探してみたけど…

TDD site:http://d.hatena.ne.jp/nowokay/
テスト site:http://d.hatena.ne.jp/nowokay/

>このへんか。もっと昔にも言ってたけどこの人発言量多いから探すの面倒だな。

いやいや、ことあるごとに懐疑的な発言をしているんなら、すぐに見つかるんじゃないの？
0150デフォルトの名無しさん2011/08/15(月) 14:57:24.37
ソフトウェアテスト総集編のTDDの記事を書いているTDD研究会のケニチロウってどうなの？

TDDにとっついてみようと本を買ったのはいいが、
ピンとこないというか勘所がわからないので、
この人の言うことをどこまで真に受けていいのかわからないw
0151デフォルトの名無しさん2011/08/16(火) 04:58:29.70
噂のRuby&Githubに特化した自動テストサービス「Travis CI」を試してみたらすごいよかった... - mochizblog
http://mochizblog.heroku.com/21

0152デフォルトの名無しさん2011/08/16(火) 11:45:59.77
>>150
(3, 4, 5)の場合をif文でいったん実装するというのはやり過ぎという議論もあるかもしれないけど、
それ以外はいたってまともで真に受けて良いよ。
0153デフォルトの名無しさん2011/08/16(火) 13:29:16.49
>>152
とん、これ参考にお盆中にゴニョゴニョがんばってみる。
0154 忍法帖【Lv=9,xxxP】 2011/09/13(火) 04:36:12.81
test
0155 忍法帖【Lv=11,xxxPT】 2011/09/14(水) 08:40:20.36
test
0156デフォルトの名無しさん2011/09/14(水) 22:59:28.96
自動化テストに対するテストはどうやって…とかグダグダ言う奴って基本的に信頼できん。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。
0157 忍法帖【Lv=19,xxxPT】 2011/09/15(木) 00:22:15.84
test
0158デフォルトの名無しさん2011/09/15(木) 13:38:38.82
でも気持ちはわからなくはないかな。

テスト対象を書いた自分が信用できないからテストを書くわけだけど、
そのテストを自分で書いたらやっぱり信用できるテストなのかとうたがいたくなるよね。

まあ実際はそんなことやてたらきりがないわけだけど。

せめてテスト内容のレビューはしたいよね。
少人数プロジェクトはテストすらかかねえからなあ。
0159デフォルトの名無しさん2011/09/15(木) 13:43:03.78
普通は「手動で行うテスト仕様書」のレビューは行われるが、
自動化テストのコードレビューは、レビューに耐えうる品質になってないのがほとんどだろうがな。
0160デフォルトの名無しさん2011/09/15(木) 14:58:42.17
テストを通すためのプログラミングをしてもだめだろ
0161デフォルトの名無しさん2011/09/15(木) 15:06:24.69
テストを通すためにプログラミング、それがTDD
0162デフォルトの名無しさん2011/09/15(木) 15:39:05.50
テストさえ通ればあとは知りまへん、それがTDD
0163 忍法帖【Lv=29,xxxPT】 2011/09/16(金) 01:45:17.33
test
0164 忍法帖【Lv=37,xxxPT】 2011/09/17(土) 00:32:32.20
test
0165デフォルトの名無しさん2011/09/17(土) 16:44:34.63
だからTDDでのテストは、本来の意味のテストじゃねぇってばw
まぁ例えるならlintの強化って感じだ

本来の意味のテストは別途行うべし
0166デフォルトの名無しさん2011/09/18(日) 18:28:33.11
だからその辺りの勘違いを嫌って
BDDって言い換えようとした流れも有ったんだが
流行んなかったなあ
0167デフォルトの名無しさん2011/09/30(金) 00:14:01.08
>>165
本来の意味でのテストってどんなテスト？
0168デフォルトの名無しさん2011/09/30(金) 08:15:58.99
実際に手動でシステムを動作させて、結果を目視確認で期待する結果と相違ないかを確認する作業。

俺も昔は自動化テストですべてまかなえると信じたくちだが、最近はやっぱり手動でもやらないとなと痛感している次第。
0169デフォルトの名無しさん2011/10/01(土) 20:10:15.37
目視確認か自動化かは悩ましい所だけど、GUI関連はコスパと変更可能性とかを考えると目視確認が妥当なんだろうな
0170デフォルトの名無しさん2011/10/02(日) 11:33:28.50
使い勝手のテストにもなるしねぇ
0171デフォルトの名無しさん2011/10/03(月) 08:18:11.42
自動化さろたテストの環境はだいぶ整備されてきてるのにそっちの方のテストはいまだにエクセル管理が多いよなぁ。
0172デフォルトの名無しさん2011/10/08(土) 16:23:55.58
継続リリースなら自動化のコストも回収できるだろうけど、単発納品が多いからなぁ
0173デフォルトの名無しさん2011/11/10(木) 23:25:22.26
過疎ってんなあ
0174デフォルトの名無しさん2011/11/14(月) 00:42:33.46
てめぇが日記でも書いていけや
■ このスレッドは過去ログ倉庫に格納されています