2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

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

1 :デフォルトの名無しさん:2010/09/19(日) 21:26:12
テスト駆動開発 (test-driven development; TDD) について マターリ 語りましょう

ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/

2 :デフォルトの名無しさん:2010/09/19(日) 21:46:07
>>1
よろしければTDD入門によいWABサイトや、
書籍などの紹介を頼みます。

3 :デフォルトの名無しさん:2010/09/19(日) 21:49:44
日本人にテストファーストはなじまないと思うよ。
作りながら考えるPGが多すぎる。かくいう俺もそうだけどw

フレームワークが出来た後なら余裕だけど、
フレームワークを作ってる最中は作業に水を差されてるみたいでなんか辛い。

4 :デフォルトの名無しさん:2010/09/19(日) 22:22:46
プロトタイプ作ってる間はテストファーストはなあ。
フレームワークありきでTDDは効果出るよね。

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

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

てか設計に掛けられる時間が少なかったり、
複数人で設計をレビューしながらまとめる文化がないよね。

5 :デフォルトの名無しさん:2010/09/19(日) 23:05:17
ここは天才チンパンジーのアイちゃん(ry

6 :デフォルトの名無しさん:2010/09/19(日) 23:48:40
>>3
作りながら考えるからこそ
テストファーストになるんじゃないのか?

7 :デフォルトの名無しさん:2010/09/20(月) 01:28:15
最近TDDじゃなくてアレだよね
名前なんていうのか忘れたけど
DDDだっけ?HDDだっけ?

8 :デフォルトの名無しさん:2010/09/20(月) 01:35:38
DDD: GNUのGUIデバッガ
HDD: ハードディスクドライブ

9 :デフォルトの名無しさん:2010/09/20(月) 02:18:41
RDDのことか

10 :デフォルトの名無しさん:2010/09/20(月) 08:17:43
テストコードって書くの楽しくないからどうしても後回しにしたくなるんだよな
どうすれば楽しくなるのかな

11 :デフォルトの名無しさん:2010/09/20(月) 10:22:31
>>6
関数書き始めたとき、その関数がどんな時にエラーを返すか
詳細に検討してないことは、ままあるな。
先に考えるのメンドクセ。

12 :デフォルトの名無しさん:2010/09/20(月) 14:18:37
ググって見つかった最初のページに


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

○基本

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

○実践

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

[link]リファクタリングとテストの関係(PDF)

13 :デフォルトの名無しさん:2010/09/20(月) 21:56:28
オライリーのビューティフルシリーズってどうなの?

ttp://www.oreilly.co.jp/catalog/soon.html
ビューティフルテスティング 978-4-87311-474-3 \\\\3,360 2010年10月

14 :デフォルトの名無しさん:2010/09/20(月) 23:44:18
>>1
スレタイにBDDもいれろ

15 :デフォルトの名無しさん:2010/09/20(月) 23:46:06
それは置いておいて、
webアプリ作る時ってプロトタイプを3日間とかもしくは2時間ぐらいで
モックとともにガゥーーーっと作るじゃん?

そういうのっていちいちBDDなんかで振る舞いや仕様を定義して・・・とかやってると
とてもじゃないが時間かかりすぎるんだけどどうしてるの?

16 :デフォルトの名無しさん:2010/09/20(月) 23:49:35
おまえ、まさかプロトタイプを本番に使ってないよな?

17 :デフォルトの名無しさん:2010/09/21(火) 01:10:31
え、、、、


ダメなの?

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

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

説明用に2時間で作ったもんは捨てれ。

19 :デフォルトの名無しさん:2010/09/21(火) 06:55:26
趣味なのか仕事なのかでも違うと思う

が、趣味でも大型の変更は一回作って傾向見て捨てて
その経験だけ頭に入れて別途作り直したほうが結局は早いな
1回目のコードを大事にしようとすると歪が溜まるのは同じ

20 :デフォルトの名無しさん:2010/09/21(火) 09:53:02
プロトタイプを実践で使いたいなら導入時にテストをかいておきたいなあ。

21 :デフォルトの名無しさん:2010/10/11(月) 20:33:31
なんかテスト駆動開発を勘違いしている奴多くないか。
全関数をテストするわけじゃなく、ある程度の単位でまとめて、そこで外部とのI/F決める。
その単位でのテストが目的で、普通は仮にでもそこを決めてから、コーディング始めるだろ。
じゃなかったら複数人での開発なんかできないぞ。

22 :デフォルトの名無しさん:2010/10/12(火) 07:07:20
>>21
テスト駆動開発やテストファーストの「テスト」という単語が勘違いされてるからな
そのために、振る舞い駆動開発などというものもでてきているんじゃないのか?
ようするに

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

なんて

23 :デフォルトの名無しさん:2010/12/22(水) 04:02:54
設計や実装の不具合がないことを示すテストじゃなくて
とりあえず実装完了を示すテストだといってみたらどうだろう

24 :デフォルトの名無しさん:2010/12/22(水) 07:01:25
プリミティブ、配列、ツリーだけでインプットとアウトプットを
構成することを規約化したらエクセルドキュメントから
テストコードを自動生成できないかな

モックとテストファーストが満たせないか

25 :デフォルトの名無しさん:2010/12/22(水) 20:20:05
テストコードからExcelファイルを自動生成すればよくね、Apache POI辺りを使って

26 :デフォルトの名無しさん:2010/12/23(木) 10:05:36
テストコードからExcel吐いたりしている人はいるらしい

Cucumberみたいな自然言語使う流れもあるけど、あれは誰に見せるものなんだよw

27 :デフォルトの名無しさん:2010/12/23(木) 14:23:43
1.テストケース(ドキュメント)
2.テストコード
3.実装

でしょ?

テストコード書いてテストケース生成するのはまずいのでは?

28 :デフォルトの名無しさん:2010/12/23(木) 20:43:31
テストコードがドキュメントみたいな開発スタイルもある
1週間で作るとか1ヶ月とかのプロジェクトだとドキュメントなんて作ってられん

29 :デフォルトの名無しさん:2010/12/24(金) 01:55:26
それは俗にいう誤ったTDD、
カウボーイ・コーディングのアジャイルでしょ

アジャイルに関する実際の需要はそっちだったりする?w

30 :デフォルトの名無しさん:2010/12/24(金) 06:57:25
安易に「誤った」なんて言っちゃうマヌケw

31 :デフォルトの名無しさん:2010/12/25(土) 14:32:58
テストコードからHTML生成やってみようかと思ったが
テストコード側が最悪に書きにくくなりそうだ
振る舞いのフローチャート化も本当に単純なことしかできそうにない

ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38

32 :デフォルトの名無しさん:2010/12/25(土) 14:52:11
>>31
Javaだったらすでにそういうツールありそうだな



33 :デフォルトの名無しさん:2010/12/25(土) 16:20:19
日本語のソースフォージにはなさそうだったから
立ち上げてみようかな。フローチャート図吐き出す案が思いついたら

34 :デフォルトの名無しさん:2010/12/25(土) 17:43:00
>31
JDaveにHTML reportってのは有る。

35 :31:2010/12/27(月) 07:16:40
垂直に上から下への一本線のフローチャートしかおもいつかないや
シーケンス図っぽくしたら良いのだろうか

36 :デフォルトの名無しさん:2010/12/27(月) 10:19:51
ユニットテストなら生成→値をセット・実行→値をゲット→検証
ぐらいの短いサイクルだけで十分

37 :デフォルトの名無しさん:2010/12/27(月) 11:42:33
RSpecの本まだー?
早う日本語で専門書だせー-

38 :デフォルトの名無しさん:2011/01/17(月) 05:52:00
粒度の高い結合テストしてから粒度の低い単体テストしないと無駄が多いって
聞いたことがあるけど

粒度の低いクラスから作っていく印象があるTDDはどうなのよ

39 :デフォルトの名無しさん:2011/01/22(土) 20:49:54
ネタがないね

40 :デフォルトの名無しさん:2011/01/23(日) 20:54:27
Twitterとかじゃ盛り上がっているようだな

41 :デフォルトの名無しさん:2011/02/05(土) 08:30:07
Fit: Framework for Integrated Test

久しぶりにあさってみるか

42 :デフォルトの名無しさん:2011/02/05(土) 12:02:06
いい参考図書はないでしょうか?

>>12の@ITの記事を参考にやってみたけどどうもシックリこないので…
・まずテストを書いて…ってどこから書くの?
・テストを書くのは関数単位?クラス単位?外部I/Fのみ?
 外部I/Fのみが一番正しそうだけど、その場合別途ユニットテストも書くの?
 内部が複雑な場合くっつけた状態でモレなくテストするのって難しいのでは?
・どこまで書いたら終わり?できたコードをみると引数チェックのヌケモレとかチラホラと
細かく回すメリットは理解できるのですがやってみると
品質も実装効率もガタ落ちなのでなにか根本的に間違えてそうな気がします。

43 :デフォルトの名無しさん:2011/02/07(月) 11:01:02
別に無理してやらなくてもいいのでは?
隣の芝生が青いだけでしょ

44 :デフォルトの名無しさん:2011/02/07(月) 11:10:00
不慣れなうちは実装効率が落ちるってのは分かるけど
品質が落ちるってのは…

新しい事に手を出すのは、余裕のある時の方がいいと思うよ

45 :デフォルトの名無しさん:2011/02/07(月) 19:25:39
おいらはTDDやったことありませんが
TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの?


46 :デフォルトの名無しさん:2011/02/07(月) 20:12:43
>>42
UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い(結果を生む)かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと(異常なパラメータを渡したときの振る舞い)が予期した結果を生成するかチェックする

それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ


47 :デフォルトの名無しさん:2011/02/07(月) 23:32:23
>>42
すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。

48 :デフォルトの名無しさん:2011/02/08(火) 07:48:30
よくあるAnimal->Dog,Catなクラスのbark関数ってどうやってテストするの?
javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もTDDツールにはあるのかな?


49 :デフォルトの名無しさん: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を置き換えればいいんじゃないかな。

50 :デフォルトの名無しさん:2011/02/09(水) 00:44:31
>>48
テストしにくい、つまり設計がよくないということがテストできた

51 :デフォルトの名無しさん: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"));


52 :デフォルトの名無しさん:2011/02/09(水) 15:18:10
csvとかファイル受け取って処理するコードのテストって、どうかくの?

53 :デフォルトの名無しさん:2011/02/09(水) 19:19:09
自分ならファイルを情報を取得する部分と
その内容を処理する部分に分けて設計し個別にテスト。

54 :デフォルトの名無しさん:2011/02/09(水) 21:02:09
えっ

55 :デフォルトの名無しさん:2011/02/15(火) 14:58:24
テスト可搬性高=コード最適化じゃないからね
リファクタリングも含めて
この辺りの誤解が未だにあるような気がする

56 :デフォルトの名無しさん:2011/02/15(火) 15:45:51
>>53のケースへの適切な対処法を具体的に聞きたいな
分けて作ったらどうダメなん?

57 :デフォルトの名無しさん:2011/02/15(火) 15:49:58
むしろ分けずに書くのはドシロウトだろ

58 :デフォルトの名無しさん:2011/02/17(木) 07:40:15
まぁ環境によるわな
メモリが少ない環境だと、ストリームから逐一取り出してゴニョゴニョしたいときもあるだろうし

59 :デフォルトの名無しさん:2011/02/17(木) 08:07:11
それでもわけるだろ

60 :デフォルトの名無しさん:2011/02/17(木) 08:10:58
分けねえよ
「ファイルを取得して目的の形式で返す」までが単一の機能だろう

61 :デフォルトの名無しさん:2011/02/17(木) 08:25:07
言語によるかもしれん
Rubyだと、なんかよくわからん細かさのメソッドが(ユーザーから隠されて)存在するほうが喜ばれる気がする
オープンクラス利用して手元で動作修正することがしばしば行われるので、クラスやメソッドがどでんと大きいと面倒

62 :デフォルトの名無しさん:2011/02/17(木) 10:34:31
>>60
ん?それが分けるってことじゃ?
@ストリームオープン
  A-1 ストリームから一行取得して目的の形式で返す
  A-2 目的の形式のデータをごにょごにょ処理して何かをアウトプット
Bデータがなくなるまでループ


63 :デフォルトの名無しさん:2011/02/17(木) 12:11:39
>>60
>「ファイルを取得して目的の形式で返す」までが単一の機能だろう
要求されているのが単一の機能だとしても、それを複数に分けてはいけないと
いうルールはない。
分けた方がテストしやすいのなら、分けるべきだろう。

64 :デフォルトの名無しさん:2011/02/17(木) 12:47:22
四の五の言わずにソース貼れや

65 :デフォルトの名無しさん:2011/02/18(金) 00:37:33
大抵はreaderとhandlerにわける

66 :デフォルトの名無しさん:2011/02/19(土) 12:18:19
結局公開インターフェースだけテストすればいいのかな
その辺のサジ加減がわからん

67 :デフォルトの名無しさん:2011/02/19(土) 12:55:17
よく言われるのは自分の不安がなくなるまでかな
これで大丈夫と思ったらテストなんて書かなくて正解
あーこんなときどうするんだろって不安に思ったらテスト書く

68 :デフォルトの名無しさん:2011/02/19(土) 13:28:24
それはちょっと違くねえか
TDD的に

69 :デフォルトの名無しさん:2011/02/19(土) 15:22:27
×不安になったらテストを書く。
○不安が出ないように事前にテストを書く。

70 :デフォルトの名無しさん:2011/02/20(日) 00:51:21.25
角谷さんの記事が参考になった
http://kakutani.com/20080216.html#p01

71 : 忍法帖【Lv=1,xxxP】 :2011/05/11(水) 10:31:59.12


72 :デフォルトの名無しさん:2011/06/14(火) 11:09:22.79
フィクスチャって、テストデータのことだよね?違う?
ひとによってはsetUp()/tearDown()のことをフィクスチャといっているんだけど、どうなん?


73 :デフォルトの名無しさん: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()のことをフィクスチャといっている
でも問題なさそう

74 :デフォルトの名無しさん:2011/06/15(水) 10:29:49.07
むしろテストデータをフィクスチャとか、マジ素人

75 :デフォルトの名無しさん:2011/06/15(水) 13:18:41.30
Wikipediaに説明があった。
ttp://ja.wikipedia.org/wiki/XUnit

> テストフィクスチャ
> テストを実行、成功させるために必要な状態や前提条件の集合を、フィクスチャと呼ぶ。
> これらはテストコンテキストとも呼ばれる。
> 開発者はテストの実行前にテストに適した状態を整え、テスト実行後に元の状態を復元することが望ましい。

これじゃ何のことか分かりにくいなあ。

76 :デフォルトの名無しさん:2011/06/15(水) 18:50:16.06
知ってる人なら意味が分かる、ってやつだな
初学の人がこれ読んだだけじゃチンプンカンプンだろう

77 :デフォルトの名無しさん:2011/06/18(土) 23:25:11.37
> これらはテストコンテキストとも呼ばれる。

これで充分わかるだろ

78 :デフォルトの名無しさん:2011/06/22(水) 14:42:58.40
テストフィクスチャは言葉の意味にぶれが結構あって文化や人によって若干違ってくる。

例えばRailsだとテストデータをyamlで用意する手段があって、それをフィクスチャと呼んでる。

基本的にはテストするために用意するテストデータやオブジェクトのことだと思っておけば大丈夫。

79 :デフォルトの名無しさん:2011/06/22(水) 16:09:43.38
>>78
ちがうよ

80 :デフォルトの名無しさん:2011/06/22(水) 16:36:00.05
テストデータっていうよりか
テストの為のお膳立てじゃね?

81 :デフォルトの名無しさん:2011/06/22(水) 17:15:39.89
>>79
なにが違うか説明してくれよ

82 :デフォルトの名無しさん:2011/06/22(水) 17:32:04.40
コピーはゼロックスだがゼロックスはコピーとは限らないだろ

83 :デフォルトの名無しさん:2011/06/22(水) 17:42:11.76
そういう関係じゃないと思う
テスト用のデータなのか、テスト用のプログラムなのかって違い

84 :デフォルトの名無しさん:2011/06/27(月) 14:42:18.25
テストの前提となる環境データその他を指すんじゃねぇの

85 :デフォルトの名無しさん:2011/06/27(月) 15:01:59.49
何でもデータの一言で片付けるのは
開発者としてどうよ

86 :デフォルトの名無しさん:2011/06/27(月) 15:20:10.96
データなんだからデータでいいだろ
data =

87 :デフォルトの名無しさん:2011/07/02(土) 00:38:39.15
まあ、とりあえずTDDといったら、日本人ならt_wadaさんだな。

88 :デフォルトの名無しさん:2011/07/04(月) 17:02:36.68
t_wadaって実践が伴ってるんだろうか

89 :デフォルトの名無しさん:2011/07/04(月) 21:57:39.91
数年前にご一緒したことありますが、プラグマティックな方でしたよ

90 :デフォルトの名無しさん:2011/07/05(火) 11:28:38.99
>>89
それは実践が伴ってるという意味?
別に全部見てるわけじゃ無いけど、最近TDDでプログラミングとかバリバリしてるようには見えない。
実践が伴わなければ本とか記事とか書くなと言うわけじゃ無いんだが、どうもうさんくさい。

91 :デフォルトの名無しさん:2011/07/05(火) 17:09:05.74
だいたい名前が売れてる人は、実際には他人のコードなのに、そいつが書いたかのような事になっている。

92 :デフォルトの名無しさん:2011/07/06(水) 20:26:40.58
>>91
そんな事実みたことねーよ。

93 :デフォルトの名無しさん:2011/07/06(水) 20:36:51.52
ぶっちゃけ他社のソース見ることはないな
うち元請けじゃないし

94 :デフォルトの名無しさん:2011/07/13(水) 00:20:56.20
t-wadaは真心。
t_wadaは下心。
Twitterで流れていたネタw

95 :デフォルトの名無しさん:2011/07/13(水) 17:00:39.07
>>94
古いね。

96 :デフォルトの名無しさん:2011/07/14(木) 08:02:22.70
こんなしょーもないネタを事情通っぽく「古いね」とか言われてもなぁ。

97 :デフォルトの名無しさん:2011/07/14(木) 09:49:55.26
おまえらTDDについて話せよ。

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

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

定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。

98 :デフォルトの名無しさん:2011/07/14(木) 11:22:03.40
別に構えてお題を用意する必要ないだろ
今までやってた業務のやつやらしゃいいじゃん

99 :デフォルトの名無しさん:2011/07/14(木) 22:29:28.39
だよなあ

100 :デフォルトの名無しさん:2011/07/15(金) 04:17:44.07
ここにいる人ってTDDBCとか出たり、テスト駆動開発入門の本を読んだりしないで
適当に実業務の中でTDDを覚えたり2chやWebの記事やblogなどで勉強した感じですかね?
少なくともTDDBCとかには出ていない雰囲気がする。。。

101 :デフォルトの名無しさん:2011/07/15(金) 12:53:11.73
ヒント:今までのTDDBCの参加のべ人数を推定してみよう

102 :デフォルトの名無しさん:2011/07/16(土) 00:39:49.48
あんなイベント出てるやつは「TDDBCに参加することでTDDをなんとなく理解をしている自分に酔ってる」と思う。
まあ、2chの練習も程度が低いので五十歩百歩だなwww

103 :デフォルトの名無しさん:2011/07/16(土) 00:40:56.78
ああいう、オフのイベントに参加できるだけリア充だと思う。
俺には考えられない。。。

104 :デフォルトの名無しさん:2011/07/16(土) 04:16:36.95
reviewで充分だよな

105 :デフォルトの名無しさん:2011/07/17(日) 22:35:19.81
>>102
入り口はそれでもいいんだよ


106 :デフォルトの名無しさん:2011/07/19(火) 17:32:31.53
bootcampに参加する奴って、人脈を広げたい奴か、自分で書籍を読み通すことができない奴か、
暇人かのどれかでしょ。

107 :デフォルトの名無しさん:2011/07/19(火) 18:57:09.08
どうした、bootcampで小馬鹿にでもされたか?

108 :デフォルトの名無しさん:2011/07/19(火) 19:23:10.60
TDDBCを叩いてる奴は和田さんに相手にしてもらえなくて悲しい思いでもしたのか?

109 :デフォルトの名無しさん:2011/07/19(火) 20:35:24.16
これは酷い

110 :デフォルトの名無しさん:2011/07/19(火) 21:19:32.09
TDDBC参加すらしたことのない小者が2chでTDD?プゲラ。

とかいいながらそれは無いわ…。引くわ…。

111 :デフォルトの名無しさん:2011/07/20(水) 11:50:04.76
なんつーか、マ板でやれお前ら

112 :デフォルトの名無しさん:2011/07/20(水) 21:38:39.32
まずは、外に出て人に会うことから始めろよwww

113 :デフォルトの名無しさん:2011/07/20(水) 21:54:26.24
堪忍して

114 :デフォルトの名無しさん:2011/07/28(木) 18:40:18.43
テストに関するオススメの良書教えて

115 :デフォルトの名無しさん:2011/07/28(木) 18:46:36.80
あげ

116 :デフォルトの名無しさん:2011/07/28(木) 21:01:34.98
良書はまだ無い、
原点のテスト駆動開発入門を写経するが吉




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

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

基本から学ぶソフトウェアテスト―テストの「プロ」を目指す人のために
ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ソフトウェアテスト293の鉄則

118 :デフォルトの名無しさん:2011/07/28(木) 21:47:37.60
本読んでTDDできると思ってるやつらおめでたすぎ。
TDDBCに参加しないと真のTDDは実践できない。

119 :デフォルトの名無しさん:2011/07/28(木) 22:09:02.48
釣りにすらなんねーだろ…w

120 :デフォルトの名無しさん:2011/07/28(木) 22:09:20.82
宗教的で気持ち悪いな

121 :デフォルトの名無しさん:2011/07/28(木) 22:16:19.16
>117
テスト駆動開発入門は確かに読みにくいけど、コードを写経する分には問題ない
1回写経してみると読みにくさも気にならないと思う

ソフトウェア技法とかの本はどっちかというと、品質保証系のテストの本。
そっちはそっちで役に立つし、TDDに応用できないかと言えば色々できるけど、別の分野と考えた方がいいかも。
良書ではあると思うよ

122 :デフォルトの名無しさん:2011/07/28(木) 23:24:00.87
TDDは慣れるものじゃなくて、理解して実践する類のもの
写経なんかすんなよ ケントベック泣いちゃうぞ

写経している奴は、ケントベックが
「他のTODOをやってみたが上手く行かないことが分かったので、先にこっちのTODOをやる」
などとさらっと書いてある部分はどうしてんだろう

123 :デフォルトの名無しさん:2011/07/29(金) 00:52:42.66
右も左も解らない状態でどうやって慣れるのさw

124 :デフォルトの名無しさん:2011/07/29(金) 20:43:51.15
テストって二つの意味があるんだよな。
設計をプログラムに落とすテスト駆動開発と。
品質を保証するテスト。

どっちもテストって名前ついているけど、
全くの別物だよ。

125 :デフォルトの名無しさん:2011/07/29(金) 22:55:13.75
そういうデベロッパーテスティングの意味を理解するだけでもTDDBCにいく意味はあると思うぞ。

126 :デフォルトの名無しさん:2011/07/31(日) 08:55:27.49
TDDについて語るスレなんだから、ここで語るんだよ。
TDDBCについて語るスレじゃねーぞw

127 :デフォルトの名無しさん:2011/08/01(月) 01:13:08.98
>117 読むなら
レガシーコード改善ガイド
+ パターン指向リファクタリング入門
で おk
補足資料として リファクタリング, テスト駆動開発入門 があればって感じだね
まぁ後、アジャイルソフトウェア開発の奥義, コードコンプリート なんかも気休めにはなるだろう。


"品質保証系のテスト"の話がしたいなら別だが。

128 :デフォルトの名無しさん:2011/08/02(火) 08:12:19.14
>>125
なんかもの凄く必死に見えるんだが、そんなにTDDBCの空席目立ったのか?


129 :デフォルトの名無しさん:2011/08/02(火) 15:00:00.36
ttp://d.hatena.ne.jp/absj31/20110731/1312209896
見たけど、なんでt-wadaがTDDのエバンジェリストっぽい立ち居地にいるのかわからん。

130 :デフォルトの名無しさん:2011/08/02(火) 15:25:14.87
>>129
優秀かつ積極的にTDDを広めようとした人が他にいなかったからじゃないか?

131 :デフォルトの名無しさん:2011/08/02(火) 22:30:09.48
いっつもt_yanoとごっちゃになる。

132 :デフォルトの名無しさん:2011/08/03(水) 01:26:15.74
>>129
じゃあ、あなたが立ち上がりましょう!大丈夫、あなたほど優秀な人ならば表の世界で活躍できる!
さあ、怖がらないで!

133 :デフォルトの名無しさん:2011/08/03(水) 18:16:09.36
>>127
ありがとう
その2つ読んでみます。
リファクタリングはちょうどオブジェクト指向の勉強として読んでいます

>>117と似たようなシリーズの「はじめて学ぶソフトウェアのテスト技法」がいつの間にか家にあったので
とりあえず読んでみようと想うのですが、>>117の3つって必要ですかね
なんか表紙が似ているので同じようなものだと嫌だなぁとw

134 :デフォルトの名無しさん:2011/08/04(木) 01:42:56.84
> 設計をプログラムに落とすテスト駆動開発
なんかニュアンス違うw

テスト駆動開発でプログラムができあがる、ってまさに設計しながらって感じで
テスト駆動開発の"前"に行う設計ってせいぜいおおまかな下書きラフスケッチみたいなものでしかない。
とてもじゃないがソースに落とせないよ

135 :デフォルトの名無しさん:2011/08/04(木) 02:26:35.10
みんな表に出て議論しようよ。
みなさんの知見をもとにより良い開発について考えていきましょう!

136 :デフォルトの名無しさん:2011/08/04(木) 21:43:36.36
個々の事例となると社外秘だったりするんで
公開の場でってのは難しいわなぁ

137 :デフォルトの名無しさん:2011/08/07(日) 10:18:32.85
BDDになるとどのくらい違うんだっけ?
イマイチ、TDDとの違いがピンと来ないんだが

138 :デフォルトの名無しさん:2011/08/07(日) 14:29:01.42
BDDはただの言い換えでしょ、Spec系の。
俺は嫌い。

139 :デフォルトの名無しさん:2011/08/07(日) 16:34:10.79
うむ

140 :デフォルトの名無しさん:2011/08/07(日) 16:41:55.68
結局BDDってなんだったの感はあるよな。
最近詳しく言及してたのは
ttp://ukstudio.jp/2011/07/02/bdd
ぐらいか?

141 :デフォルトの名無しさん:2011/08/07(日) 17:22:20.47
滝への回帰としか思えん

142 :デフォルトの名無しさん:2011/08/08(月) 01:29:11.62
和田さん入籍おめでとうございます。

143 :デフォルトの名無しさん:2011/08/08(月) 14:43:54.15
テスト駆動開発ってプログラミングを楽にするけど、
メインは、プログラマーの底上げを図るための物だよね。
だから力がある人や、それと同等の力のある人同士で
プロジェクトを作成する人には不要だね。


144 :デフォルトの名無しさん:2011/08/08(月) 15:31:50.53
力がある人もプログラミングを楽にできるのだが

145 :デフォルトの名無しさん:2011/08/08(月) 22:27:31.26
きしださんとか事あるごとにテストに懐疑的な発言してるけど、あの人が言うと業界にいい加減な人を増やすだけだからやめてほしい。

勉強熱心なのは認めるけど、それを解釈する脳ミソや、実践する態度に疑問を感じてならない。

146 :デフォルトの名無しさん:2011/08/09(火) 11:28:30.47
>>145
誰?
どこに何を発言したの?
見たこと無いけど。

147 :デフォルトの名無しさん:2011/08/10(水) 18:58:30.33
このへんか。もっと昔にも言ってたけどこの人発言量多いから探すの面倒だな。

TDDとか「TDDはあなたの心のなかにあります」みたいなあいまいな言葉なんだから、技術用語として使うのはどうかと思う。その言葉を使って意思疎通ができてない。混乱にしかならないので、この言葉ははやめに葬るほうがいい気がするよ。
https://twitter.com/#!/kis/status/100050996616642560
それもこれもケントベックというペテン師が悪い。
https://twitter.com/#!/kis/status/100051107589537792

148 :デフォルトの名無しさん:2011/08/10(水) 23:42:41.43
良いテストを構築できるかどうかがプログラマの腕の見せ所だろ?

149 :デフォルトの名無しさん: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/

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

いやいや、ことあるごとに懐疑的な発言をしているんなら、すぐに見つかるんじゃないの?

150 :デフォルトの名無しさん:2011/08/15(月) 14:57:24.37
ソフトウェアテスト総集編のTDDの記事を書いているTDD研究会のケニチロウってどうなの?

TDDにとっついてみようと本を買ったのはいいが、
ピンとこないというか勘所がわからないので、
この人の言うことをどこまで真に受けていいのかわからないw

151 :デフォルトの名無しさん:2011/08/16(火) 04:58:29.70
噂のRuby&Githubに特化した自動テストサービス「Travis CI」を試してみたらすごいよかった... - mochizblog
http://mochizblog.heroku.com/21



152 :デフォルトの名無しさん:2011/08/16(火) 11:45:59.77
>>150
(3, 4, 5)の場合をif文でいったん実装するというのはやり過ぎという議論もあるかもしれないけど、
それ以外はいたってまともで真に受けて良いよ。

153 :デフォルトの名無しさん:2011/08/16(火) 13:29:16.49
>>152
とん、これ参考にお盆中にゴニョゴニョがんばってみる。

154 : 忍法帖【Lv=9,xxxP】 :2011/09/13(火) 04:36:12.81
test

155 : 忍法帖【Lv=11,xxxPT】 :2011/09/14(水) 08:40:20.36
test

156 :デフォルトの名無しさん:2011/09/14(水) 22:59:28.96
自動化テストに対するテストはどうやって…とかグダグダ言う奴って基本的に信頼できん。
じゃあ、お前は手動で行うテスト仕様書に対してテスト仕様書書いて実施してんのかと。
どっちも最終的にはレビューして担保するしかねーんだよ。

157 : 忍法帖【Lv=19,xxxPT】 :2011/09/15(木) 00:22:15.84
test

158 :デフォルトの名無しさん:2011/09/15(木) 13:38:38.82
でも気持ちはわからなくはないかな。

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

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

せめてテスト内容のレビューはしたいよね。
少人数プロジェクトはテストすらかかねえからなあ。

159 :デフォルトの名無しさん:2011/09/15(木) 13:43:03.78
普通は「手動で行うテスト仕様書」のレビューは行われるが、
自動化テストのコードレビューは、レビューに耐えうる品質になってないのがほとんどだろうがな。

160 :デフォルトの名無しさん:2011/09/15(木) 14:58:42.17
テストを通すためのプログラミングをしてもだめだろ

161 :デフォルトの名無しさん:2011/09/15(木) 15:06:24.69
テストを通すためにプログラミング、それがTDD

162 :デフォルトの名無しさん:2011/09/15(木) 15:39:05.50
テストさえ通ればあとは知りまへん、それがTDD

163 : 忍法帖【Lv=29,xxxPT】 :2011/09/16(金) 01:45:17.33
test

164 : 忍法帖【Lv=37,xxxPT】 :2011/09/17(土) 00:32:32.20
test

165 :デフォルトの名無しさん:2011/09/17(土) 16:44:34.63
だからTDDでのテストは、本来の意味のテストじゃねぇってばw
まぁ例えるならlintの強化って感じだ

本来の意味のテストは別途行うべし

166 :デフォルトの名無しさん:2011/09/18(日) 18:28:33.11
だからその辺りの勘違いを嫌って
BDDって言い換えようとした流れも有ったんだが
流行んなかったなあ

167 :デフォルトの名無しさん:2011/09/30(金) 00:14:01.08
>>165
本来の意味でのテストってどんなテスト?

168 :デフォルトの名無しさん:2011/09/30(金) 08:15:58.99
実際に手動でシステムを動作させて、結果を目視確認で期待する結果と相違ないかを確認する作業。

俺も昔は自動化テストですべてまかなえると信じたくちだが、最近はやっぱり手動でもやらないとなと痛感している次第。

169 :デフォルトの名無しさん:2011/10/01(土) 20:10:15.37
目視確認か自動化かは悩ましい所だけど、GUI関連はコスパと変更可能性とかを考えると目視確認が妥当なんだろうな

170 :デフォルトの名無しさん:2011/10/02(日) 11:33:28.50
使い勝手のテストにもなるしねぇ

171 :デフォルトの名無しさん:2011/10/03(月) 08:18:11.42
自動化さろたテストの環境はだいぶ整備されてきてるのにそっちの方のテストはいまだにエクセル管理が多いよなぁ。

172 :デフォルトの名無しさん:2011/10/08(土) 16:23:55.58
継続リリースなら自動化のコストも回収できるだろうけど、単発納品が多いからなぁ

173 :デフォルトの名無しさん:2011/11/10(木) 23:25:22.26
過疎ってんなあ

174 :デフォルトの名無しさん:2011/11/14(月) 00:42:33.46
てめぇが日記でも書いていけや

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)