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

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

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

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

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

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

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

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

○基本

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

○実践

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

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

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

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


ダメなの？
2010/09/21(火) 01:33:37
おまwww

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

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

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

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

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

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

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

でしょ？

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

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

ttp://www.filebank.co.jp/filelink/133adb79503b26f344fad4fea1d0cf38
2010/12/25(土) 14:52:11
>>31
Javaだったらすでにそういうツールありそうだな

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

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

久しぶりにあさってみるか
2011/02/05(土) 12:02:06
いい参考図書はないでしょうか？

>>12の@ITの記事を参考にやってみたけどどうもシックリこないので…
・まずテストを書いて…ってどこから書くの？
・テストを書くのは関数単位？クラス単位？外部I/Fのみ？
　外部I/Fのみが一番正しそうだけど、その場合別途ユニットテストも書くの?
　内部が複雑な場合くっつけた状態でモレなくテストするのって難しいのでは？
・どこまで書いたら終わり？できたコードをみると引数チェックのヌケモレとかチラホラと
細かく回すメリットは理解できるのですがやってみると
品質も実装効率もガタ落ちなのでなにか根本的に間違えてそうな気がします。
43デフォルトの名無しさん
垢版 |
2011/02/07(月) 11:01:02
別に無理してやらなくてもいいのでは？
隣の芝生が青いだけでしょ
2011/02/07(月) 11:10:00
不慣れなうちは実装効率が落ちるってのは分かるけど
品質が落ちるってのは…

新しい事に手を出すのは、余裕のある時の方がいいと思うよ
2011/02/07(月) 19:25:39
おいらはTDDやったことありませんが
TDDとかBDD のテストやスペックは
あとで細かい大量のテストを書くための布石ぐらいに考え
大雑把なものでいいというわけにはいかないの？
2011/02/07(月) 20:12:43
>>42
UnitTestはクラスの振る舞いをチェックするものだから公開されているインターフェースを使ったときに正しい振る舞い（結果を生む）かどうかがチェックされればそれでいいのだよ
テストが足りないと感じるときは、起きてはいけないこと（異常なパラメータを渡したときの振る舞い）が予期した結果を生成するかチェックする

それで品質が落ちるってのは根本的に間違ったコードってことじゃんよ
2011/02/07(月) 23:32:23
>>42
すごいわかる。自分も同じ気持ち。
なれるまでは、あまり効果でないよね。
2011/02/08(火) 07:48:30
よくあるAnimal->Dog,Catなクラスのbark関数ってどうやってテストするの？
javaであればSystem.out.print("Mew");, C++なら cout<<"Mew"; ってのがちゃんと出てるかテストするような道具もＴＤＤツールにはあるのかな？
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を置き換えればいいんじゃないかな。
2011/02/09(水) 00:44:31
>>48
テストしにくい、つまり設計がよくないということがテストできた
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"));
2011/02/09(水) 15:18:10
csvとかファイル受け取って処理するコードのテストって、どうかくの？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況