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

1 ：2010/09/19 〜 最終レス ：2013/01/29

テスト駆動開発 (test-driven development; TDD) について ﾏﾀｰﾘ 語りましょう
ツールについては別スレで
テストツールについて語るスレ 2
http://hibari.2ch.net/test/read.cgi/tech/1208013693/

2 ：

>>1
よろしければTDD入門によいWABサイトや、
書籍などの紹介を頼みます。

3 ：

日本人にテストファーストはなじまないと思うよ。
作りながら考えるPGが多すぎる。かくいう俺もそうだけどｗ
フレームワークが出来た後なら余裕だけど、
フレームワークを作ってる最中は作業に水を差されてるみたいでなんか辛い。

4 ：

プロトタイプ作ってる間はテストファーストはなあ。
フレームワークありきでTDDは効果出るよね。
フレームワークもある程度固まったらテスト書かないとふあんだけど。
ドラフト状態部分のフレームワーク部分はテストを後に回してもいいキガス。
てか設計に掛けられる時間が少なかったり、
複数人で設計をレビューしながらまとめる文化がないよね。

5 ：

ここは天才pンジーのアイちゃん（ｒｙ

6 ：

>>3
作りながら考えるからこそ
テストファーストになるんじゃないのか？

7 ：

最近TDDじゃなくてアレだよね
名前なんていうのか忘れたけど
DDDだっけ？HDDだっけ？

8 ：

DDD: GNUのGUIデバッガ
HDD: ハードディスクドライブ

9 ：

RDDのことか

10 ：

テストコードって書くの楽しくないからどうしても後回しにしたくなるんだよな
どうすれば楽しくなるのかな

11 ：

>>6
関数書き始めたとき、その関数がどんな時にエラーを返すか
詳細に検討してないことは、ままあるな。
先に考えるのメンドクセ。

12 ：

ググって見つかった最初のページに
↓
以下は参考サイトのまとめ
○基本
[link]テスト駆動開発とPDCAサイクル - 開発者がテスト駆動開発をすると、生産性が上がる理由
[link]@IT - 「テスト駆動開発」はプログラマのストレスを軽減するか？
[link]テスト駆動開発やユニットテストを定着させるには
○実践
実際の開発では、すべてのコードに対してテストコードを書くなんてのは不可能。
どのコードに対してテストコードを書くと効果的か（価値があるか）、その判断基準の参考になる。
[link]リファクタリングとテストの関係(PDF)

13 ：

オライリーのビューティフルシリーズってどうなの？
ttp://www.oreilly.co.jp/catalog/soon.html
ビューティフルテスティング 978-4-87311-474-3 \\\\3,360 2010年10月

14 ：

>>1
スレタイにBDDもいれろ

15 ：

それは置いておいて、
webアプリ作る時ってプロトタイプを3日間とかもしくは2時間ぐらいで
モックとともにガゥーーーっと作るじゃん？
そういうのっていちいちBDDなんかで振る舞いや仕様を定義して・・・とかやってると
とてもじゃないが時間かかりすぎるんだけどどうしてるの？

16 ：

おまえ、まさかプロトタイプを本番に使ってないよな？

17 ：

え、、、、

ダメなの？

18 ：

おまwww
捨てるプロトタイプと、コア実装としてのプロトタイプが
あるとは思うけど、後者はちゃんと設計して作るもんだ。
説明用に2時間で作ったもんは捨てれ。

19 ：

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

20 ：

プロトタイプを実践で使いたいなら導入時にテストをかいておきたいなあ。

21 ：

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

22 ：

>>21
テスト駆動開発やテストファーストの「テスト」という単語が勘違いされてるからな
そのために、振る舞い駆動開発などというものもでてきているんじゃないのか？
ようするに
　「あれは(お前らが考えてる)テストじゃないんだ。振る舞いを定義してるんだ」
なんて

23 ：

設計や実装の不具合がないことを示すテストじゃなくて
とりあえず実装完了を示すテストだといってみたらどうだろう

24 ：

プリミティブ、配列、ツリーだけでインプットとアウトプットを
構成することを規約化したらエクセルドキュメントから
テストコードを自動生成できないかな
モックとテストファーストが満たせないか

25 ：

テストコードからExcelファイルを自動生成すればよくね、Apache POI辺りを使って

26 ：

テストコードからExcel吐いたりしている人はいるらしい
Cucumberみたいな自然言語使う流れもあるけど、あれは誰に見せるものなんだよw

27 ：

1.テストケース（ドキュメント）
2.テストコード
3.実装
でしょ？
テストコード書いてテストケース生成するのはまずいのでは？

28 ：

テストコードがドキュメントみたいな開発スタイルもある
1週間で作るとか1ヶ月とかのプロジェクトだとドキュメントなんて作ってられん

29 ：

それは俗にいう誤ったＴＤＤ、
カウボーイ・コーディングのアジャイルでしょ
アジャイルに関する実際の需要はそっちだったりする？ｗ

30 ：

安易に「誤った」なんて言っちゃうマヌケw

31 ：

テストコードからHTML生成やってみようかと思ったが
テストコード側が最悪に書きにくくなりそうだ
振る舞いのフローチャート化も本当に単純なことしかできそうにない
ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38

32 ：

>>31
Javaだったらすでにそういうツールありそうだな

33 ：

日本語のソースフォージにはなさそうだったから
立ち上げてみようかな。フローチャート図吐き出す案が思いついたら

34 ：

>31
JDaveにHTML reportってのは有る。

35 ：

垂直に上から下への一本線のフローチャートしかおもいつかないや
シーケンス図っぽくしたら良いのだろうか

36 ：

ユニットテストなら生成→値をセット・実行→値をゲット→検証
ぐらいの短いサイクルだけで十分

37 ：

RSpecの本まだー？
早う日本語で専門書だせー-

38 ：

粒度の高い結合テストしてから粒度の低い単体テストしないと無駄が多いって
聞いたことがあるけど
粒度の低いクラスから作っていく印象があるTDDはどうなのよ

39 ：

ネタがないね

40 ：

Twitterとかじゃ盛り上がっているようだな

41 ：

Fit: Framework for Integrated Test
久しぶりにあさってみるか

42 ：

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

43 ：

別に無理してやらなくてもいいのでは？
隣の芝生が青いだけでしょ

44 ：

不慣れなうちは実装効率が落ちるってのは分かるけど
品質が落ちるってのは…
新しい事に手を出すのは、余裕のある時の方がいいと思うよ

45 ：

おいらはTDDやったことありませんが
TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの？

46 ：

>>42
UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い（結果を生む）かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと（異常なパラメータを渡したときの振る舞い）が予期した結果を生成するかチェックする
それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ

47 ：

>>42
すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。

48 ：

よくあるAnimal->Dog,Catなクラスのbark関数ってどうやってテストするの？
javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もＴＤＤツールにはあるのかな？

49 ：

>>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 ：

>>48
テストしにくい、つまり設計がよくないということがテストできた

51 ：

一応、Javaでも可能。
うろ覚えだがこんな感じ
ByteArrayOutputStream out = new ByteArrayOutputStream();
System.setOut(new PrintWriter(out));
//テスト実行
String text = new String(out.getBytes());
assertThat(text, is("baw"));

52 ：

csvとかファイル受け取って処理するコードのテストって、どうかくの？

53 ：

自分ならファイルを情報を取得する部分と
その内容を処理する部分に分けて設計し個別にテスト。

54 ：

えっ

55 ：

テスト可搬性高＝コード最適化じゃないからね
リファクタリングも含めて
この辺りの誤解が未だにあるような気がする

56 ：

>>53のケースへの適切な対処法を具体的に聞きたいな
分けて作ったらどうダメなん？

57 ：

むしろ分けずに書くのはドシロウトだろ

58 ：

まぁ環境によるわな
メモリが少ない環境だと、ストリームから逐一取り出してゴニョゴニョしたいときもあるだろうし

59 ：

それでもわけるだろ

60 ：

分けねえよ
「ファイルを取得して目的の形式で返す」までが単一の機能だろう

61 ：

言語によるかもしれん
Rubyだと、なんかよくわからん細かさのメソッドが（ユーザーから隠されて）存在するほうが喜ばれる気がする
オープンクラス利用して手元で動作修正することがしばしば行われるので、クラスやメソッドがどでんと大きいと面倒

62 ：

>>60
ん？それが分けるってことじゃ？
�@ストリームオープン
　　�A-1 ストリームから一行取得して目的の形式で返す
　　�A-2 目的の形式のデータをごにょごにょ処理して何かをアウトプット
�Bデータがなくなるまでループ

63 ：

>>60
>「ファイルを取得して目的の形式で返す」までが単一の機能だろう
要求されているのが単一の機能だとしても、それを複数に分けてはいけないと
いうルールはない。
分けた方がテストしやすいのなら、分けるべきだろう。

64 ：

四の五の言わずにソース貼れや

65 ：

大抵はreaderとhandlerにわける

66 ：

結局公開インターフェースだけテストすればいいのかな
その辺のサジ加減がわからん

67 ：

よく言われるのは自分の不安がなくなるまでかな
これで大丈夫と思ったらテストなんて書かなくて正解
あーこんなときどうするんだろって不安に思ったらテスト書く

68 ：

それはちょっと違くねえか
TDD的に

69 ：

×不安になったらテストを書く。
○不安が出ないように事前にテストを書く。

70 ：

角谷さんの記事が参考になった
http://kakutani.com/20080216.html#p01

71 ：

72 ：

フィクスチャって、テストデータのことだよね？違う？
ひとによってはsetUp()/tearDown()のことをフィクスチャといっているんだけど、どうなん？

73 ：

>フィクスチャとは、テスト・ケースのもととなるオブジェクトの集合です
http://www.metabolics.co.jp/XP/cppunit-doc/cookbook.htm
>テストコードにおいて、ある状態にオブジェクトを設定するためのコードを、テストの「フィクスチャ（土台）」と呼びます。
http://d.hatena.ne.jp/asakichy/20100405/1270437389
らしいから
>setUp()/tearDown()のことをフィクスチャといっている
でも問題なさそう

74 ：

むしろテストデータをフィクスチャとか、マジ素人

75 ：

Wikipediaに説明があった。
ttp://ja.wikipedia.org/wiki/XUnit
> テストフィクスチャ
> テストを実行、成功させるために必要な状態や前提条件の集合を、フィクスチャと呼ぶ。
> これらはテストコンテキストとも呼ばれる。
> 開発者はテストの実行前にテストに適した状態を整え、テスト実行後に元の状態を復元することが望ましい。
これじゃ何のことか分かりにくいなあ。

76 ：

知ってる人なら意味が分かる、ってやつだな
初学の人がこれ読んだだけじゃvンカンプンだろう

77 ：

> これらはテストコンテキストとも呼ばれる。
これで充分わかるだろ

78 ：

テストフィクスチャは言葉の意味にぶれが結構あって文化や人によって若干違ってくる。
例えばRailsだとテストデータをyamlで用意する手段があって、それをフィクスチャと呼んでる。
基本的にはテストするために用意するテストデータやオブジェクトのことだと思っておけば大丈夫。

79 ：

>>78
ちがうよ

80 ：

テストデータっていうよりか
テストの為のお膳立てじゃね？

81 ：

>>79
なにが違うか説明してくれよ

82 ：

コピーはゼロックスだがゼロックスはコピーとは限らないだろ

83 ：

そういう関係じゃないと思う
テスト用のデータなのか、テスト用のプログラムなのかって違い

84 ：

テストの前提となる環境データその他を指すんじゃねぇの

85 ：

何でもデータの一言で片付けるのは
開発者としてどうよ

86 ：

データなんだからデータでいいだろ
data =

87 ：

まあ、とりあえずTDDといったら、日本人ならt_wadaさんだな。

88 ：

t_wadaって実践が伴ってるんだろうか

89 ：

数年前にご一緒したことありますが、プラグマティックな方でしたよ

90 ：

>>89
それは実践が伴ってるという意味？
別に全部見てるわけじゃ無いけど、最近TDDでプログラミングとかバリバリしてるようには見えない。
実践が伴わなければ本とか記事とか書くなと言うわけじゃ無いんだが、どうもうさんくさい。

91 ：

だいたい名前が売れてる人は、実際には他人のコードなのに、そいつが書いたかのような事になっている。

92 ：

>>91
そんな事実みたことねーよ。

93 ：

ぶっちゃけ他社のソース見ることはないな
うち元請けじゃないし

94 ：

t-wadaは真心。
t_wadaは下心。
Twitterで流れていたネタｗ

95 ：

>>94
古いね。

96 ：

こんなしょーもないネタを事情通っぽく「古いね」とか言われてもなぁ。

97 ：

おまえらTDDについて話せよ。
ということで話題を投下。ちょっと新人にTDD教えるのにペアプロしようと思うんだがなにかいいお題はないかな。
言語はRubyで仕事はRailsだけど、とりあえずTDDについておしえたいのでWebアプリをお題にするのは避けようと思ってる。
定番どころだとボーリングなのかもしれんが、サンプルとしてあまり良い気がしないんだよな。

98 ：

別に構えてお題を用意する必要ないだろ
今までやってた業務のやつやらしゃいいじゃん

99 ：

だよなあ

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【計測】LabVIEW相談室【制御】 (566)
SSE AVXのプログラミング (744)
【Lua】組み込み系言語総合 その5【Squirrel】 (928)
リファクタリングがしやすいのは、静的型付け言語 (409)
OpenMPプログラミング (388)
Borland C++ Compiler オ　ワ　タ (326)
--log9.info------------------
Borderlands2 Part31 (789)
【Paradox】War Of The Roses【薔薇戦争】5 (481)
【GTA4】Grand Theft Auto �W MODスレ part10 (747)
【BF3】 BATTLEFIELD 3 noob限定 Vol.1 (764)
さあ、お前らのPCのスペックを晒すんだ (814)
Team Fortress 2 初心者スレ Part21 (301)
△【十】 Team Fortress 2 交換スレ part43 【十】 (758)
【WarZ】The War Z Vol.24 (894)
【PC】 DARK SOULS Part27 (704)
【BF3】スナイパー【芋砂】 (282)
FPSに最適なヘッドフォン・スピーカー Part24 (928)
真夏のR夢inPCACTION 第四章 (427)
【PC】Medal of Honor: Warfighter Part3【MoH:W】 (398)
□■ HALF-LIFE2 ハーフライフ2 ■□Part 150 (942)
Origin Part2 (263)
【PC】バイオハザード5 part14【BIOHAZARD】 (393)
--log55.com------------------
やっぱワイドプリンタブルっしょ
【流出】あきばんぐ 【顧客情報】
☆過去に焼いた激安メディアの生存率★
書き込み失敗したメディアの活用法　その1
【国産】　MB　を語り尽くすｽｯﾄﾞﾚ　【高品質？】
【06年は】DVDﾄﾞﾗｲﾌﾞのCD焼き【低速焼きの危機】
店舗オリジナルメディアを語れ
【収納】DISK STAKKA 【管理】