【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ってのは有る。

35312010/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
てめぇが日記でも書いていけや

175デフォルトの名無しさん2012/01/23(月) 03:37:03.56
ユニットテストとは:
想定した入力や操作に対して
プログラマーが想定した結果が返ってくることを確認する工程。

本来のテストとは:
乱数入力やきまぐれ操作によって
プログラマーが想定してなかった欠陥を探す工程。

176デフォルトの名無しさん2012/01/23(月) 21:11:03.75
添削

誤:本来のテストとは ....
正:俺様のテストの定義では ....

177デフォルトの名無しさん2012/01/24(火) 06:25:19.24
>>175
ユニットテストというのはあくまでユニット(関数、クラス、モジュール等)に対するテストという意味だよ。
対比されるべきは結合テスト(複数のユニットに渡るテスト)とか。

プログラマーの想定の範囲内でテストするか、想定の範囲外をテストするかで分類するなら
もう少し別の分類の言葉があると思う。
TDDBCの人が言ってるような、Developer testing、Customer testing、QA testingという
分類がそれに当たるのかもしれない。

178デフォルトの名無しさん2012/01/24(火) 23:29:13.81
>>176
「真の」とか「本当の」とかも同類だねw

179デフォルトの名無しさん2012/02/07(火) 00:06:45.40
>ユニットテストと対比されるべきは結合テスト
結合テストも広義のユニットテストだと思うけど、違うの?

>想定の範囲内でテストするか、想定の範囲外をテストするか
プログラムわからん人に説明するなら分かりやすくていいと思う
仕様の定義漏れテスト

180デフォルトの名無しさん2012/02/07(火) 14:06:58.57
>>179
> 結合テストも広義のユニットテストだと思うけど、違うの?
違う。

> >想定の範囲内でテストするか、想定の範囲外をテストするか
> プログラムわからん人に説明するなら分かりやすくていいと思う
> 仕様の定義漏れテスト
一体何に対する説明なのか良くわからんが、説明する必要がある人(ステークホルダーとか)への
説明なら全然駄目。

181デフォルトの名無しさん2012/02/10(金) 10:51:53.71
TestCaseクラスを、どの単位で作ればいいか迷う。
たとえば
class Foo {
 def method1() {
 }
 def method2() {
 }
}
があったとして、
RSpecなら
describe Foo do
 describe '#method1()' do
  it "...spec#1..." do ... end
  it "...spec#2.." do ... end
 end
 describe '#method2()' do
  it "...spec#1..." do ... end
  it "...spec#2.." do ... end
 end
end
というふうに、クラス単位・メソッド単位でテストを自然に記述できる。
(つづく)

182デフォルトの名無しさん2012/02/10(金) 10:58:15.99
(つづき)
しかしxUnit系のツール(JUnitとかTest::Unitとか)だと、DSLじゃなくてクラス定義構文とメソッド定義構文を使うから、
こんなかんじ↓になって、テストの記述が不自然になってしまう。

class FooTest(Test::Unit::TestCase)
 # for method1
 def test_method1__spec1() ... end
 def test_method1__spec2() ... end
 # for method2
 def test_method2__spec1() ... end
 def test_method2__spec2() ... end
end

かといって、メソッドごとにクラス定義を分ける↓のは、細かくなり過ぎてやりたくない。

class Foo_method1_Test(Test::Unit::TestCase)
 def test_spec1() ... end
 def test_spec2() ... end
end
class Foo_method2_Test(Test::Unit::TestCase)
 def test_spec1() ... end
 def test_spec2() ... end
end

で、みんなどうしてるんだろうか。


183デフォルトの名無しさん2012/02/10(金) 11:41:52.71
そんな開発者全体で見ると、使用者の割合が0.1%のRubyの話題出されても困ります。

184デフォルトの名無しさん2012/02/11(土) 08:41:31.64
>>183
使用者の割合が0.01%のPythonだと誰も読めないと思って、Rubyにしました。
RSpecはRubyだしね。

185デフォルトの名無しさん2012/02/11(土) 09:07:55.35
Ruby以外の言語だと、XML等でテスト仕様を記述して
そこからテストコードを自動生成するんじゃまいかと思う
いわゆる外部DSLだね

あと、利用者の割合あれこれというより、
Rubyの柔軟性をフル活用した内部DSLであるRSpecをここで持ち出されても、
他の言語利用者には気の毒というか、変態的だと気味悪がられるだけw

186デフォルトの名無しさん2012/02/11(土) 11:10:38.08
PythonやHaskellだとコメントにテストを書くdoctestも定番ですよ

187デフォルトの名無しさん2012/02/12(日) 05:37:05.23
>>181
>TestCaseクラスを、どの単位で作ればいいか迷う。
と書いてあるんだから、別にどの言語であろうと、自分はこういう単位で作ってると教えてあげればいい。
RubyだのRSpecだのにとらわれてるやつは読解力なさすぎ。

自分の場合、Fooクラスに対してFooTestクラスを作り、Fooクラスの機能や仕様ごとに
テストメソッドを書いている。
Fooクラスのメソッド単位での分類はしてない(したいときもあるけど、今はしてない)。

188デフォルトの名無しさん2012/02/13(月) 15:45:37.60
>>184
Pythonも0.1%。
Java(14.2%), C++(10%), C#(5.1%)あたりでよろしく。

189デフォルトの名無しさん2012/02/13(月) 15:47:13.64
>>187
あのー、スレタイ読んで出直してくれます?

190デフォルトの名無しさん2012/02/14(火) 11:02:17.12
TDDの場合、頻繁に変更中のクラスのテストを実行するわけだから、テストクラスは
テスト対象クラス単位の方が良い。
そうしないと、class FooTestにclass Barとclass Bazのテスト用が入っている場合、
Bar/Bazのどちらを変更するときも、関係無いクラスのテストを実行しなければならなくなる。

一方、TDDで実行するテストはUnit Testであるという側面を考えた場合、各テストメソッドは
独立している必要がある(テストメソッドが相互に他のテストメソッドに影響を与えてはならない)。
そうすると、最も親和性の高いものはxUnitである。

xUnitはsetUp()->testMethod()->tearDown()という流れでテストが実行される。
上記でテストクラスはテスト対象クラス単位が良いと書いたが、このxUnitの仕組みにより、
テスト対象クラスが同じでもsetUp()の内容が大幅に異なる場合に限り、一つのテスト対象
クラスに対して、複数のテストクラスに分割するということもありえる。
ただし、そのようにせざるを得ないというのはごくまれで、そうしたいと思う時は大抵
テスト対象クラスの責務が大きすぎる。

191デフォルトの名無しさん2012/02/14(火) 15:46:07.43
>>190
>テストクラスは
>テスト対象クラス単位の方が良い。
これに同意するんだけど、その場合、「メソッド」という単位をどう扱ったらいいの?
ちょうど>>182で書かれていることなんだけど。

class FooTest extends TestCase {
 function test_method1_should_return_string() { ... }
 function test_method1_should_throw_error_when_invalid_arg() { ... }
 function test_method2_should_return_integer() { ... }
 function test_method2_should_throw_error_when_invalid_arg() { ... }
}

こんな感じになってるんだけど、こうしかないのかな。
やっぱりテストを入れ子で書けるRSpecがうらやましい。

192デフォルトの名無しさん2012/02/14(火) 17:13:24.75
>>191
> やっぱりテストを入れ子で書けるRSpecがうらやましい。

個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
基本的に、class Foo編集時は、class FooTest全体を実行するから。

入れ子をすることが、テストメソッド群をグルーピングすることだけが目的なのであれば、そのような
機能を持つUnit Testing Frameworkもある。(アノテーションを使ったりする)

>>182の後半の書き方(クラスを分ける)のは感心しない。
何度も言うようだが、class Foo編集時は、そのクラス全体が壊れていないのを確認しながら編集するので、
class Fooに対するテスト全部を実行しながら編集を行う。
そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。

テストメソッドの粒度の話であれば、1テストメソッドは1テストケースの為のものであるべきというのが結論。

193デフォルトの名無しさん2012/02/15(水) 09:02:08.58
>>192
>個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
それがすごく大事なんじゃないか。

>そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
テストを複数のクラスに分割すること自体は悪くはないと思う。

なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。

194デフォルトの名無しさん2012/02/15(水) 11:44:29.23
>>193
> >個人的には、入れ子で書けたとしても、見た目がすっきりする以外のメリットはあまり感じない。
> それがすごく大事なんじゃないか。

見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない?

> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
> テストを複数のクラスに分割すること自体は悪くはないと思う。

複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
テストクラスを複数に分割することの是非は分けて考えなければならない。

自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。

また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。

> なんか話の節々からJavaerっぽい感じを受けるけど、Javaでもpublicなinnerクラスを作って、
> ひとつのファイルに複数のテストクラスを入れるってことはしないのかな。

Javaは使ってない。
また、前述したとおり、一つのファイルに複数のテストクラスを入れることもしない。

195デフォルトの名無しさん2012/02/15(水) 11:53:55.66
テストを複数のクラスに分割することのデメリットをまとめておく。

1. class Fooのテストがどのテストクラスにあるのか一目でわからない
2. 起動が面倒になる(テストツールもある)
3. (これまで言わなかったが)複数のテストクラスで共通の処理が必要な場合に、
  テストクラスが一つであった場合よりもコーディングが面倒になる。
  コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。

逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう?
個人的には、特に見当たらないのだが……。

196デフォルトの名無しさん2012/02/15(水) 13:25:20.41
一ファイル一クラスが前提なのか、一ファイル複数クラスなのかがごっちゃになってる気がする

197デフォルトの名無しさん2012/02/15(水) 20:39:13.34
テスト駆動なのに、駆動する前にどんなクラスを作るか決めちゃうの?

198デフォルトの名無しさん2012/02/15(水) 20:45:13.85
どんなクラスを作るか決める

テストを作る

クラスを実装する

どんなクラスを作るか決めなきゃテストは作れねーよ

正確には「クラスのインタフェースだけはキッチリ決める、実装は決めない」。当然ブラックボックスで。

200デフォルトの名無しさん2012/02/16(木) 10:33:22.15
>>197
クラスとテストクラスを成長させてく過程で、テストクラスをどいう風に作ってけばいいかって話でしょ

201デフォルトの名無しさん2012/02/16(木) 10:33:56.30
>>194
>見た目だけが大事なのであれば、コメントで区切るとかすればいいんじゃない?
入れ子にして階層的に表示できるから見やすくなる。コメントで区切るのは見やすくならない。

>> >そのため、class Fooに対するテストが複数テストクラスに分かれていると、テスト実行が面倒になる。
>> それは複数のテストクラスを実行するのが面倒なテストツールが悪いのであって、
>> テストを複数のクラスに分割すること自体は悪くはないと思う。
>
>複数のテストクラスを実行するのが簡単なテストツールが存在するということと、
>テストクラスを複数に分割することの是非は分けて考えなければならない。
うん、その通り。
そして「テストが複数テストクラスに分かれていると、テスト実行が面倒になる」と言い出したのはそっちなんだけどね。

>自分の場合は、FooTestを実行する場合、コマンドラインで「xunitスペースFo[Tab][Return]」で実行する。
>TDDの場合、1分に複数回テストを実行する場合もあるので、起動が面倒だと地味にストレスがたまる。
うん、だからそれは「複数のテストクラスを実行するのが面倒なテストツールが悪い」のであって、
テストを複数のクラスに分割することの是非とは関係ないよね。

>また、第三者がメンテナンスを引き継ぐ場合、1クラス1テストクラスの原則に沿ってない場合、
>どのテストクラスがどのクラスのテストなのかを把握するのが大変になる。
だから、それは「どのテストクラスがどのクラスのテストなのかを把握するのが大変になる」ようなコードを書いているのが悪いのであって、
テストを複数のクラスに分割することの是非とはあんまり関係ないよね。


202デフォルトの名無しさん2012/02/16(木) 10:40:08.70
>>195
>テストを複数のクラスに分割することのデメリットをまとめておく。
>
>1. class Fooのテストがどのテストクラスにあるのか一目でわからない
わかるようなコードの書き方は可能。そう書かないのが悪い。

>2. 起動が面倒になる(テストツールもある)
そんなテストツールを使うのが悪い。

>3. (これまで言わなかったが)複数のテストクラスで共通の処理が必要な場合に、
>  テストクラスが一つであった場合よりもコーディングが面倒になる。
>  コーディングが面倒になるということは、積極的なテストクラスのリファクタリングの妨げにもなる。
はい?共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。

>逆に、1クラス1テストクラスの原則を守るとした場合のデメリットは何だろう?
>個人的には、特に見当たらないのだが……。
もともとは、>>182>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。
それに、今のxUnit系ツールはsetUpとtearDownがクラスごとにひとつだから、
違うsetUpとtearDownを使いたい場合はテストクラスを分けざるを得ない。
つまり1クラス1テストクラスだとfixtureが1種類に固定される。

203デフォルトの名無しさん2012/02/16(木) 11:13:49.50
>>201
> テストを複数のクラスに分割することの是非とはあんまり関係ないよね。

テストを複数のクラスに分割すると、50個のクラスのテストが200個のテストクラスになったりする。
さて、class Fooに対するテストはどのファイルにあるのか簡単にわかるだろうか。
そして、class Barにメソッドを追加したくなったとき、どのファイルにテストを追加すればいいか、簡単にわかるだろうか。

これはテストコードの書き方が良いとか悪いとかの話では無くて、テストクラスの管理の話だね。
自分はこううまく管理するから問題ない、こううまくテストコードを書くから問題ないという特殊化を
するんじゃなくて、一般的に「1クラス1テストクラス」という原則を採用する/しない場合のメリットと
デメリットを話すので無ければ、あまりこの議論に価値を見いだせない。

> はい?共通の親クラスを作る、委譲を使う等、いくらでも手はあるけど。

プロダクトコードをどう実装するかの話と、DevelopmentをDrivenするTestコードなんだから、
素早く、シンプルに、なおかつ重複コードなどないテストコードを書けるようにしておいた方が良くない?
「1クラス1テストクラス」なら、共通の親クラスを作る必要も、委譲を使う必要も無く、ただ単に
private methodを一つ追加すればいいだけだよね。

> もともとは、>>182>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。

そう。そして>>190は俺のコメント。

そうせざるを得ない場合をのぞいて、テストを複数のクラスに分割することのメリットを話してよ。

204デフォルトの名無しさん2012/02/16(木) 11:14:46.80
s/プロダクトコードをどう実装するかの話と/プロダクトコードをどう実装するかの話ではなくて/

205デフォルトの名無しさん2012/02/16(木) 11:33:16.62
例えば、
-----------------
class XmlOutputter
-----------------
+addHook()
+removeHook()
+write()
+setStyleSheet()
+setRootNode()
+addFailedTest()
+addSuccessfulTest()
+addStatistics()

みたいなクラスを実装しようとしているとき、各メソッド用のテストが5個できるとすると、
テストメソッドは合計40個できることになるけど、これってclass XmlOutputterTestに全部入ってれば、
自分も含めて誰もがどこに何のテストがあるかすぐにわかるし、どんなツールでも簡単に
class XmlOutputterのテストを全部実行できる。
分かり易くない?

206デフォルトの名無しさん2012/02/16(木) 11:55:55.23
そもそも>>182の上のコードを不自然と感じる感性がわからんわ

207デフォルトの名無しさん2012/02/16(木) 12:33:32.95
見づらい見づらいって、コード折りたたみ機能があるIDEかエディター使えよ

208デフォルトの名無しさん2012/02/16(木) 19:40:28.42
ケントベックの本だと、
いきなり最初からテストクラスとそこから作ったクラスが違う
あとの方でクラスを抽象化してテストクラスの名前と同じようにしてるけど
結果論なのか始めから見通しを立ててたからか

あんなのTDDじゃないとかいう人もいるけど

209デフォルトの名無しさん2012/02/16(木) 20:00:14.54
ケントベック式TDDならTODO駆動なのだから
TODOの分類とフィクスチャでテストクラスを割り当てていくんだろうなぁ

210デフォルトの名無しさん2012/02/17(金) 10:36:38.68
ケントベック本の例は、今考えると自動受け入れテスト用コードっぽい気がする

211デフォルトの名無しさん2012/02/17(金) 10:53:12.35
>>208
TDDBCなんかだと、Stackクラスを作るからStackTestね、てな感じで誰も疑問を覚えずスルーだよ

212デフォルトの名無しさん2012/02/17(金) 11:11:51.43
        lヽ ノ l        l l l ヽ   ヽ
  )'ーーノ(  | |  | 、      / l| l ハヽ  |ー‐''"l
 / T  | | |/| ハ  / / ,/ /|ノ /l / l l l| l  T ヽ
 l   ・  i´ | ヽ、| |r|| | //--‐'"   `'メ、_lノ| /  ・  /
 |  D  l  トー-トヽ| |ノ ''"´`   rー-/// |  D |
 |  ・   |/     | l ||、 ''"""  j ""''/ | |ヽl  ・ |
 |  D   |       | l | ヽ,   ―   / | | l  D  |
 |   !!  |     / | | |   ` ー-‐ ' ´|| ,ノ| | |  !! |
ノー‐---、,|    / │l、l         |レ' ,ノノ ノハ、_ノヽ
 /        / ノ⌒ヾ、  ヽ    ノハ,      |
,/      ,イーf'´ /´  \ | ,/´ |ヽl      |
     /-ト、| ┼―- 、_ヽメr' , -=l''"ハ    |  l
   ,/   | ヽ  \  _,ノーf' ´  ノノ  ヽ   | |
、_    _ ‐''l  `ー‐―''" ⌒'ー--‐'´`ヽ、_   _,ノ ノ
   ̄ ̄   |           /       ̄

213デフォルトの名無しさん2012/02/19(日) 12:47:19.61
> もともとは、>>182>>190に書いてあるように、メソッドという単位をどう扱うかの話だよ。

クラスを単位とするテストは、複数のメソッドにまたがることもあるから、
メソッド単位で分けられない場合もあるよ。

関数型プログラミング的な、メソッドの返す結果がそのメソッドの引数のみによって
決まる場合は、純粋にメソッドを単位としたテストができるけど、
オブジェクト指向プログラミングにありがちな、更新系のメソッドと参照系のメソッドがあって、
それらを順次呼び出すようなテストをする場合は、メソッド単位に分けにくい。

だから、テストを対象のメソッドによって分類するとか、それをテストコードでどう表現するか
という普遍的な方針は立てにくい。
はっきりした方針が立てられないのであれば、始めから分けない方が考えなくていい分楽だし、
分けるにしてもあまり分け方に拘らず依存せずゆるくやっていった方がいいと思う。

214デフォルトの名無しさん2012/02/20(月) 10:12:32.84
>>213
このスレ、TDDスレなんだけど

215デフォルトの名無しさん2012/02/20(月) 15:47:45.19
どんな言語・開発環境でも、一つのクラス対一つのテスト用クラスに勝るものはないと思う。
ただ、一つのテスト用クラスに何百ものテストメソッドがあって、実行するのに5秒とかかかるのなら
わけたくなると思うけど、そんなでかいテスト用クラス作ったこと無い。

216デフォルトの名無しさん2012/02/28(火) 14:45:23.66
1クラス-1テストクラスじゃない構成でやってる奴がいるのに驚いた。

217デフォルトの名無しさん2012/04/21(土) 21:51:02.83
これ一番の敵は自分の意識だな
ついつい先にコード書きたくなってモヤモヤしちゃう

218デフォルトの名無しさん2012/04/21(土) 22:56:13.23
全くだ
自制心が試されるよクソっ

219デフォルトの名無しさん2012/04/25(水) 00:12:32.14
JavaのServerSocket#accept()みたいなブロッキングメソッドを使うメソッドって
どうテストすればいいんだろう

220デフォルトの名無しさん2012/04/25(水) 11:49:37.34
「自分は頭が良くて詳しいです」的な自己満足レスの典型だぞ。
相手は超初心者なんだからもう少し優しく教えてあげないと。
さもなくばスルーでOK

221デフォルトの名無しさん2012/05/10(木) 22:50:42.22
eclipse+java でオススメのテストプラグインおしえてくだしゃあ

222デフォルトの名無しさん2012/06/22(金) 10:47:09.07
「Rational テスト仮想化/自動化ソリューション」
テスト期間10日が10分に!日本IBMが仮想テスト環境ツール 2012年06月22日 06時00分更新
ttp://ascii.jp/elem/000/000/703/703943/
 6月21日、日本IBMは仮想的なテスト環境を自動構築するソリューション
「Rational テスト仮想化/自動化ソリューション」を発表した。

 Rational テスト仮想化/自動化ソリューションは、テスト対象となるシステムへの入出力を
仮想的かつ自動的に再現する機能を持つ。これにより、テスト対象システムと接続するシステムの
完成を待ったり、稼働を停止する必要がなくなり、テスト環境を実際に構築することなく接続テストを
実施できる。結果として、テスト時間の短縮やテスト環境構築への投資と手間の削減が実現する。
 また、仮想化環境での接続テストが可能になることで、システム開発工程の早い段階で
不具合の修正ができるため、開発の最終段階での大幅な変更や品質問題発覚による開発遅延の
低減が可能となり、顧客へのサービス開始の遅れや追加コストの発生を防ぐとしている。
 たとえば、海外の金融機関では、テストの大部分を自動化できたことで、手作業による
テスト期間を10日から10分に削減したという。また、ある製造企業は、従来6カ月かかっていた
システム構築を2カ月短縮し、4カ月で完成させたとしている。
 IBM Rational テスト仮想化/自動化ソリューションの使用料金は、4000万円(100PVU)から。

223デフォルトの名無しさん2012/06/22(金) 11:44:41.54
10日を10分で実行できる環境を整えるのに、20日かかるとか

224デフォルトの名無しさん2012/10/09(火) 17:59:06.08

225デフォルトの名無しさん2012/10/14(日) 17:07:49.10
仕様書が先にできているときに限って
テスト駆動開発は出来る。

つまり、現実的には無理

226デフォルトの名無しさん2012/10/14(日) 17:17:10.03
>>225
アジャイルと組合せるんじゃねの?

227デフォルトの名無しさん2012/10/14(日) 17:37:55.63
仕様なしでどうやって書くんだ

228デフォルトの名無しさん2012/10/15(月) 03:15:49.84
どこの世界線の現実なんだ

229デフォルトの名無しさん2012/10/21(日) 11:00:46.22
>>225
開発手法だからアジャイルとウォーターフォールをごちゃ混ぜにしているだろ。

施工方法を根幹から変えて、仕事を受ける方法も根幹から変えないとテスト駆動開発は無理。

230デフォルトの名無しさん2012/10/22(月) 16:02:45.79
>>225
関数やクラスメソッドを実装するとき、
そのれらをテストするコード先に書くのがテストファーストだっけ?

テスト駆動はどんなんだっけ?

231デフォルトの名無しさん2013/01/06(日) 22:49:09.88
Windows で、googletest ライブラリを MinGW gcc 使ってコンパイルしたんだけど、
テストプログラムの実行ファイルのサイズがわりとデカイような気がするんだが。

http://www.atmarkit.co.jp/fdotnet/cpptest/cpptest02/cpptest02_02.html

これは CppUnit でテストしてる例だけど、
同じ例を googletest でテストする実行ファイルを作ると、
googletest を静的にリンクするように作った場合は7MBくらい。
動的リンクするように作った場合でも6MB後半くらい。

こんなもの?
テスト対象が小さすぎるから、ファイルがでかく感じるだけ?

232デフォルトの名無しさん2013/01/11(金) 22:15:15.06
試してないけど、strip コマンドでデバッグシンボル削って小さく出来ないかな?

233デフォルトの名無しさん2013/01/19(土) 19:00:11.13
>>232
ありがと、確かに小さくなった。

数個のユニットテストを作るだけでも
こんなに大きくなるのかという思いは拭えんが、
まぁそういうものだと思う事にするよ。

234デフォルトの名無しさん2013/01/20(日) 14:26:02.13
ゲーム製作において、自動化できる受け入れテストはあるか?

235デフォルトの名無しさん2013/01/29(火) 21:14:09.89
テスト駆動のテストは単体テストあるよ

236デフォルトの名無しさん2013/01/29(火) 21:52:26.88
>>235
実践テスト駆動開発(http://www.amazon.co.jp/dp/4798124583

これには受け入れテストもあるが

このスレでは単体テスト限定という意味?

237デフォルトの名無しさん2013/03/07(木) 22:25:23.26
配列の値を個々テストしたい
配列の中身の型も要素数も決まってる。要素数は10。

というか、単に配列の添字が違うだけで、それらの要素について行う処理やテスト項目は同じ。

だからテストもループで回したくなってしまう。
でもテストコードでループ使ってassertを繰り返すのっていいの?

それとも記載が冗長になるのを我慢してテストコードをコピペしては添字を変えていくのがいいの?

その辺についてスタンダードや、あるいは解説した文書などありましたらお教えください

238デフォルトの名無しさん2013/03/07(木) 23:02:09.96
>>237
> だからテストもループで回したくなってしまう。

それが正解。

> でもテストコードでループ使ってassertを繰り返すのっていいの?

ループで回す先の要素の失敗によって
後続のテストに信頼性が失われるのなら、
assertを使うべき。

各要素がそれぞれ他の要素から独立しており、
個々のテストの成否が他のテストに影響を与えないのなら、
テストの成否に関わらず後続のテストを続けるタイプの
テスト関数(マクロ)を使うべき。
(例えば gtest なら EXPECT_* マクロ)

239デフォルトの名無しさん2013/03/07(木) 23:55:12.86
>>238
ありがとうございます。

各要素は独立していたので、テストを継続するタイプのマクロを使用することに、
ループで繰り返すことにしました。

240デフォルトの名無しさん2013/03/08(金) 07:02:25.85
ちなみに、後続のテストの信頼性が失われるかどうかの判断は、
意外に難しかったりするから注意。

理論上は依存しない仕様のプログラムが、
本当に依存していないかどうかを調べるのも
テストする動機のひとつであることを忘れずに。

241デフォルトの名無しさん2013/03/08(金) 11:53:10.03
TDDなんだから、失敗したらそこで終了で良いのでは?
何で続けたいのかしら。

242デフォルトの名無しさん2013/03/08(金) 12:36:28.56
>>241
独立したテストなら、結果を一覧できた方が作業効率が良い

243デフォルトの名無しさん2013/03/08(金) 14:31:30.19
>>242
ちょっと言ってることが良くわからない。

ひょっとして「後続のテスト」と言ってるのは、
function test1() {}
function test2() {}
function test3() {}
とあったときの、test1()実行後のtest2(), test3()のこと?

もしそうだとしたら、test1(), test2(), test3()は、それぞれ独立したものにすべき。
各テストメソッドの成功/失敗や実行順序でテストの信頼性が失われるなんてもってのほか。

「後続のテスト」が
function test()
{
asssert("test 1");
asssert("test 2");
asssert("test 3");
}
のtest1のアサーション後のtest2, test3のことだとするなら、それはtest1が失敗したところで終了でいいのではということ。
TDDなんだから。

244デフォルトの名無しさん2013/03/08(金) 14:38:22.75
というか、

>>238
> テストの成否に関わらず後続のテストを続けるタイプの
> テスト関数(マクロ)を使うべき。
> (例えば gtest なら EXPECT_* マクロ)

これも良くわからない。
普通のテストツールって、テストが失敗しても後続のテストは続けるんじゃないの?
gtestは知らないけど、gtestってテストが失敗したらそこで終わっちゃうの?

「後続のテスト」というのが、あるテストメソッド内の複数のassertionのことなら前述した通り。

245デフォルトの名無しさん2013/03/08(金) 14:53:32.40
質問者が回答者にレスするスレはここですか?

246デフォルトの名無しさん2013/03/08(金) 17:01:39.12
質問者が回答者にレスしても何も問題ないと思うが、それはともかく、>>243,244は俺なんだが質問者ではない。

なんだか良くわからん質問>>237に対して、さらに良くわからん>>238という回答がついてたのでコメントした。

247デフォルトの名無しさん2013/03/08(金) 19:54:01.96
>>243
例えば、2つの変数 a と b があり、これをそれぞれある値にするための
「計算方法をテストしたい」とする。

私が言った「後続のテスト」とは、a をテストしてから b をテストする場合の、
b のテストの方を指す。

ここで、b の計算には直接的あるいは間接的に a の値を用いるとする。

この場合、a のテストがパスしなければ、b のテストには意味が無くなる。
なぜなら、本来 b の計算のテストと言えば、b の計算方法がテストできる事を期待し、
b の計算に使用する材料は全て正しいものという前提で行うが、
これでは a の結果が間違っているから b のテストがパスしないのか、
b の計算方法が間違っているから b のテストがパスしないのか分からない。
つまり、b の計算方法を正しくテストしているという確証が得られない。
だから a のテストにパスしなければ、そこでテストを止めるべきだ。

しかし、b の計算に a の値が使われない場合、
a の計算方法のテストと b の計算方法のテストは独立している。
よって、たとえ a のテストがパスしなくても、b のテストは問題なく行える。

また、このように後者の場合において、a のテストと b のとテストを同時に行う方が
テストの作業効率が良い場合も少なくない。
例えば、a と b のそれぞれの計算は独立しているが、もっと大きな枠組みにおいて、
a と b(やその他のものが)合わさってある一つの機能を実現している場合などだ。
その機能をテストする前に個々の要素をテストしているのなら、
a と b などの独立したテストの結果は一望できた方が良いと私は思う。

248デフォルトの名無しさん2013/03/08(金) 22:21:28.50
>>247
アホなの?
aのテストがパスするまで実装とテストを繰り返してからbの実装をするか、stubやmock使えよ。

249デフォルトの名無しさん2013/03/08(金) 23:47:04.07
それもそうか

250デフォルトの名無しさん2013/04/28(日) 19:09:53.06
これから本買って読もうと思いますが、TDDにxUnit的ツールは必須なんでしょうか
コンソールに結果出力するだけでもいいのでしょうか

251デフォルトの名無しさん2013/04/28(日) 19:34:15.22
あった方が断然楽しい

252デフォルトの名無しさん2013/04/28(日) 20:08:05.56
あった方がいいのは分かりますが、必須ではなさそうですね
HEW+ルネサスコンパイラで、ツール買う予算も取れないので、assertとprintfで凌ぎます

253デフォルトの名無しさん2013/04/29(月) 21:09:30.71
組込みやってるやつは可哀想だ
しかもルネとはw

254デフォルトの名無しさん2013/04/29(月) 21:41:33.37
>>252はアホ

255デフォルトの名無しさん2013/04/30(火) 15:46:55.50
コンソールがあって、さらにはprintfとassertが使えるなら、xUnitも使えるだろうが

256アホ2013/05/01(水) 05:26:40.17
CUnitとかCppUnit etcって、makeする時に実行されるもんじゃないの?
バイナリ実行すればコンソールに表示されるようなもんなの?

257アホ2013/05/01(水) 08:04:01.43
CUnit入れてコンパイルまでは通したけど、全部FAILEDになるぜドチクショウ
スレ汚し失礼しました

258デフォルトの名無しさん2013/06/27(木) 08:16:11.07
>>247
stubあんのにそんな長文、恥ずかしくないの?

259デフォルトの名無しさん2013/07/12(金) NY:AN:NY.AN
TDD始めてみたんだが、暗号化するメソッドと複合化するメソッドがあって、あるデータを暗号化して複合したらもとのデータ戻るってテストはどうやって書くのがいいの?

260デフォルトの名無しさん2013/07/12(金) NY:AN:NY.AN
既知の平文と暗号文の対を用意して
「平文→暗号化メソッド→暗号文」 というテストと
「暗号文→復号メソッド→平文」 というテストをすればいいと思うよ

261デフォルトの名無しさん2013/07/22(月) NY:AN:NY.AN
>>260
既知の暗号文無いから暗号文を求めようとしても、手で計算するのがものすごく大変。
計算機で計算しようとしても、その数式がコードそのものだから本末転倒なんだよね。

262デフォルトの名無しさん2013/07/22(月) NY:AN:NY.AN
知らんがな(´・ω・`)
いかに大変でも期待通りの暗号化処理が正しくなされてるか確認するためには最低1回は答え合わせをせざるを得なかろうよ

263デフォルトの名無しさん2013/07/24(水) NY:AN:NY.AN
>>261はTDD以前に自分が何をテストしなければならないのかすら
分かってない気がする

264デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
>>263
もしかしてこういうのってテストしなくてもいいの?

265デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
TDDのテストは開発者が設計実装を駆動するためのホワイトボックステストで、
開発者がテストとコードを両方見て主観的にコードが正しいことに確信を持てる程度のものにする。

暗号化とか神経質にならざるを得ないかもしれないが
その品質用テストを用意するのはTDDの範疇外というだけで
要らないものではないと思われ

266デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
仕様書に入出力(平文と暗号文)のサンプルくらい記載されているもんじゃないのか
それコピペすれば最低限のテストはできる思うけど

入出力が分からないんじゃTDD以前の問題だわ

267デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
>>265
そうなのだろうが、暗号化するコードなのに肝心の「暗号化できているか」をまったく調べることができないと、コードの正しさに確信が持てないんだよなあ。
というかTDDのテストってブラックボックスじゃないの?

268デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
>>266
やっぱり出力を先に手計算しといたほうがいいのかな?
add(1,1) == 2 になることを調べるテストだって、右辺の2は前もって人間が計算してるわけだし。

ただ今回の場合は簡単な解が無くて、暗号化計算してわけのわからん値になったもの同士を比較するテストをして通っても、そのメソッドが正しいという確信が得られるような気がしないんだよなあ。
そんなテストよりは、暗号文の特性、複合すると元に戻ることとかを調べたほうが直感的な気がしたんだが…なんかもやもやする。

269デフォルトの名無しさん2013/07/28(日) NY:AN:NY.AN
>>268
たとえば解の候補が3パターンあるとして
@顧客の解(要望)…AESで作ってほしい
A設計者の解(仕様書)…Twofishを採用しよう
B>>268の解(実装)…分けわからんが0xABCDでビットマスクで実装すればいいんだよな?

で、>>268がやろうとしているのは「B」をパスするテストコードを書くってことだ
それをパスすることに意味はあるのか? 「@=A=B」なら問題ないが

270デフォルトの名無しさん2013/07/29(月) NY:AN:NY.AN
>>269
どういうこと?
すまん、さっき「解」っていったのは、メソッドの返す値って意味で。
複合すると元に戻るっていうのを調べるテストは、それをパスする他のアルゴリズムがあるから、仕様をテストが表現できていないって感じの意味か?確かに、そう考えるとやばそう…。

だが手計算で計算するのが大変で、プログラムのテストというより、自分の計算のテストになりそうなんだけど。結構時間もかかるだろうし。

271デフォルトの名無しさん2013/08/01(木) NY:AN:NY.AN
そもそも単体テストってassert(expression)だから、expressionを自分で定義できなきゃやりようがないわな

272デフォルトの名無しさん2013/10/19(土) 14:06:55.25
マジでどうしたらいいかわからん助けて

encryptメソッドの仕様は
encrypt(text, pass) = salt+aes(sha(pass)+text, pass, salt)
salt=sha(rand)
aesはaes暗号、shaはハッシュ関数のやつ、randは乱数、+は文字列の結合な。
あと、textやpassは空文字でもok

decrypt(crypt, pass)はそれの復号メソッドで、もしcryptにaesの復号エラーにならないようなでたらめな値入れられても、復号文の先頭のsha(pass)が一致しなければ自作例外を投げる仕様。

お前らならどうテストすんの?

273デフォルトの名無しさん2013/10/19(土) 20:41:24.25
レスに書いてあることそのままテストすりゃいいんじゃないの

274デフォルトの名無しさん2013/10/19(土) 21:46:37.57
crypt = encrypt(text, pass);
try {
decrypted = decrypt(crypt, pass);
assert(decrypted == text);
}
catch {
assert(false);
}
try {
decrypt(nonsense_crypt_not_aes_decrypt_error, pass);
assert(false);
}
catch {
assert(true);
}

275デフォルトの名無しさん2013/12/06(金) 15:11:53.63

276デフォルトの名無しさん2013/12/26(木) 15:53:04.30

277デフォルトの名無しさん2013/12/26(木) 17:18:52.11
メソッドの名前をリファクタリングで変更するだけで
テスト毎ぶっこわれる動的言語ではTDDは辛すぎる

278デフォルトの名無しさん2014/01/13(月) 10:28:34.81
CUI のアプリを作っているのですが、ユーザーからの入力や、
それに対する出力などをテストしたいです。

ビジネスロジックの方では、入力と出力の関係は既に正しくテストされている前提です。
あくまで、UI の部分のテストの話です。

CUI用のUIテスト自動化フレームワークは何かないでしょうか。


[環境]
Linux

279デフォルトの名無しさん2014/01/13(月) 11:15:01.01
>>278
シェルスクリプト書けばいいだけでは?

280デフォルトの名無しさん2014/01/13(月) 11:19:04.03
追加。入力周りは昔はexpectというtclの拡張コマンドがよく使われてたけど、今はtclなんて流行らないよね…。
たぶん、perlとか、他のスクリプト言語にもexpect相当のライブラリがあるのでは?

2812782014/01/13(月) 11:42:00.72
なるほど、確かに。
自分の得意なスクリプト言語で作ればいいんですよね。

頭が堅すぎたようです。

ありがとうございました。

282デフォルトの名無しさん2014/01/14(火) 08:16:34.22
TAPを出すシェルスクリプトを書いて
proveでテスト実行とかかな

283デフォルトの名無しさん2014/01/26(日) 12:33:01.79
テスト駆動流行りだけど、誰がどこを勝手に直すかわからないOSSみたいな
開発形態では意図せぬデグレートが起きないように抑止する効果はあっても、
きちんと統制が取れた企業内開発じゃさして意味ないよなあ。
最初から通るテストを書いているわけで、結局コードを書いているのと同じ
レベルになって、バグは入り込むわけだし。

284デフォルトの名無しさん2014/01/26(日) 12:34:16.46
テストせやかて工藤

285デフォルトの名無しさん2014/01/26(日) 12:37:38.39
>>283
根本的にOSSというのを勘違いしているから
その後に発言が無意味になってる。

286デフォルトの名無しさん2014/01/27(月) 11:19:03.88
> 最初から通るテストを書いているわけで、結局コードを書いているのと同じ
> レベルになって、バグは入り込むわけだし。

それはテストコードと言えないだろうね
テストが通れば確実にバグってない事が保証出来るコードでないと意味ないよね
ようするに単純なテストを積み重ねていく感じか

287デフォルトの名無しさん2014/01/27(月) 15:53:46.32
仕様に明記されていないことはやらない(コードに落とさない)
仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

288デフォルトの名無しさん2014/01/27(月) 17:11:28.38
コードをテストに合わせるからバグが減る
テストをコードに合わせてはいけない

289デフォルトの名無しさん2014/01/28(火) 08:16:11.34
TDDで後から実行可能なテストも手に入るのはオマケやで
出来てしまったテストを捨てることもないだろうが
あくまで開発を前に進ませる手段や

290デフォルトの名無しさん2014/01/28(火) 08:17:03.85
> 仕様に明記されていないことはやらない(コードに落とさない)
> 仕様に明記されている内容はまずテストコードに落とし、次にコードを書き、テストを通す

仕様等の出発点からどのように粒度を落としていくか(設計していくか)の方向性として
テストするという観点を掲げているのがケントベックが本で語ったTDDなのだが
この開発の最初に必要とされるであろうステップが
日本語のWebサイト上のいろいろある解説ではびっくりするくらい完全に無視されている

291デフォルトの名無しさん2014/01/28(火) 08:36:37.02
何見て解説してるのかわからんな

292デフォルトの名無しさん2014/01/28(火) 11:12:20.43
>>290
TDDのそもそもの意味/意図である「テスト駆動」の「駆動」を忘れてるのか知らないのか無視してる奴が多いね。
なんとなくのイメージで「xUnitを使って自動テストをしながらコードを書く」くらいの理解の奴が多い感じ。

293デフォルトの名無しさん2014/01/28(火) 13:08:16.58
Test First と Test Driven はどう違う?

294デフォルトの名無しさん2014/01/28(火) 13:48:03.51
>>293
ざっくり言えば、TDD = Design First + Test First + Refactoring

295デフォルトの名無しさん2014/01/28(火) 15:13:31.12
>「駆動」を忘れてるのか知らないのか無視してる奴が多い

スレタイのせいかもな

296デフォルトの名無しさん2014/01/28(火) 18:22:31.47
BDDと形式手法の違いって?

297デフォルトの名無しさん2014/01/28(火) 18:34:16.93
>>296
形式手法って何?

298デフォルトの名無しさん2014/01/28(火) 21:50:39.87
テストを書くときの気持ちのこと

299デフォルトの名無しさん2014/01/29(水) 10:13:17.67
ぐぐればすぐ出てくるものを即座に質問する
これを脊髄駆動レスと呼びます

300デフォルトの名無しさん2014/01/29(水) 12:52:40.18
>>299
>>296のことなのか、>>297のことなのか

301デフォルトの名無しさん2014/01/31(金) 10:18:11.76
ぐぐれ

302デフォルトの名無しさん2014/02/02(日) 04:03:14.23
こんなスレあったのか
しかもだいぶ前からあるとは

俺はTDDは必要だと思ってる
元々ゴリゴリコーディングして、デバッガー使ったりで人力でテストしてって感じだったけど、
思想を知ってから、あぁこんな洗練されたものがあったのかと思った
昔はテストなんて面倒くさいと思ってたけど、それでも思想を知ってからは無理して身体に覚えさせた
慣れだよね

DBやマルチプロセスとかの問題は言われてるけど、使い分けじゃないの?
有用なときは使い 、効率悪いときは別のやり方
完璧なものなんてないだろうし

なぜ流行らなかったとか別スレあるという事は、皆あんまテストしないのか?
しても後から曖昧にとか?

303デフォルトの名無しさん2014/02/02(日) 07:00:16.31
>>302
TDDはテストじゃねーよ。

テストのフリした違うものを使って開発する方法。
作ったテストもどきはテストとしては使わない。
使い捨てのコード。

やっぱりお前はわかっていない。

304デフォルトの名無しさん2014/02/02(日) 08:56:36.07
> 作ったテストもどきはテストとしては使わない。
> 使い捨てのコード。

は?

305デフォルトの名無しさん2014/02/02(日) 13:36:26.27
>>303
じゃぁお前は、また、お前の会社はどうやってテストだけでなく、開発をしてるんだ?
開発のプロセスを聞いてみたい

306デフォルトの名無しさん2014/02/02(日) 17:35:46.13
>>304,305
俺は303じゃないけど
たぶんお前らはTDDを理解してない
もしくは一部を見て言ってる

307デフォルトの名無しさん2014/02/02(日) 18:00:48.70
ああ、こりゃ「じゃあTDDって何だよ」って問うてもまともに答えられない展開ですわ

308デフォルトの名無しさん2014/02/02(日) 18:54:00.78
【TDD】テスト駆動開発【TestFirst】

309デフォルトの名無しさん2014/02/02(日) 19:03:43.35
TDDの良い所は、コーディングがキチっとなることだと思う
テストがどうとかじゃなく、ブレがないというか

DBがどうとか言うけど、スタブ、モックオブジェクト、なんやらあるだろ

310デフォルトの名無しさん2014/02/02(日) 20:02:31.60
俺こそがTDDの神祖
おまいらは邪教徒じゃ

311デフォルトの名無しさん2014/02/02(日) 20:48:15.81
BDDって使ったことないけど、どう違うの?
TestMethod()とかがUnittestだけど、
BDDの場合はshouldBeEmpty()とかになるんだろ?

312デフォルトの名無しさん2014/02/03(月) 14:30:29.47
>>307
> 「じゃあTDDって何だよ」って問うてもまともに答えられない

その質問は、ググればすぐにわかるから誰も答えないんじゃないの?
ちなみに、Googleの第一位はWikipediaですごくまとまってる。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA

313デフォルトの名無しさん2014/02/03(月) 14:33:11.18
>>304,305
>>303の文章は酷いが、Wikipediaを読めば理解できると思う。

> テスト駆動開発で用いられるテストは、品質のためのテストではない。コード本体とは独立に
> あらゆるケースを網羅するような、テスト自体で価値を持つようなものは目指していない。
> コード本体を合わせて検討することで、開発者が、その正しさに確信を得るものである。
> 開発者の確信に少しも寄与しないテスト(かつ、ドキュメントとしてテストの読者に何かを
> 伝えるために書かれたものではないもの)は、むしろ積極的に削除を検討する。

314デフォルトの名無しさん2014/02/03(月) 17:06:00.43
俺は、TDDで作ったテストメソッドの大部分は、「品質のためのテスト」でも使えるよう修正してくよ。

315デフォルトの名無しさん2014/02/03(月) 18:38:14.74
>>313
そういうことだよな。

393 名前:デフォルトの名無しさん[sage] 投稿日:2014/02/02(日) 08:52:46.17
TDDでコーディングより先に書くテストっていうのは
ちゃんとしたテストじゃないんだ。
本番用のテストとして使えるものもあるが、使い捨てのテストも多い。
だから本番用のテストは別にちゃんと書かないといけない。

つまりこういうことなんだ。

「仮テスト→コーディング→本テスト」 VS 「コーディング→本テスト」

316デフォルトの名無しさん2014/02/03(月) 19:40:04.51

317デフォルトの名無しさん2014/02/05(水) 08:51:07.35
テストをTDDで開発してるのか

318デフォルトの名無しさん2014/02/05(水) 18:24:02.84
t_wadaさんによるスライド
「TDD のこころ @ OSH2014」
http://www.slideshare.net/t_wada/osh2014-sprit-of-tdd

『テスト駆動開発入門』も
『リファクタリング』も
『達人プログラマー』も
絶版になってたなんて……。

319デフォルトの名無しさん2014/02/07(金) 16:30:20.46
>>318
「達人プログラマー」ってなんか東亜プランの中の人かとオモタ

320デフォルトの名無しさん2014/02/07(金) 21:50:41.56
TDDの最大のメリットはテストしやすいソースになる事

321デフォルトの名無しさん2014/02/08(土) 13:05:21.69
昔社内の文書でテスト騒動って書いている奴がいて笑った
そりゃ、テストで騒動が起きるのは困るよね

322デフォルトの名無しさん2014/02/08(土) 13:09:53.56
テストで騒動とかプロジェクト毎に起きてるぜ

323デフォルトの名無しさん2014/02/08(土) 17:19:52.71
>>321を素で駆動と読んでイミフだったが>>322で読み直してすっきりさっぱりだよ。

324デフォルトの名無しさん2014/02/09(日) 23:04:23.44
まぁ、バグが発生するのはテスト中だからな

325デフォルトの名無しさん2014/02/12(水) 03:55:25.26
完成してなくてもいいから、コンパイルの通らないコードをリポジトリに登録するな、
でないと全体のコンパイルに支障が出る、というのと似たような感じで、
テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
他のモジュールの開発に支障が出るから、ってことかね。

326デフォルトの名無しさん2014/02/12(水) 11:29:02.29
>>325
> テストを通していないモジュールを登録するな、暫定的でもそれなりに動作するようなモジュールができていないと、
これは別にTDDに限った話じゃないだろ

327デフォルトの名無しさん2014/02/12(水) 13:59:27.22
テストを“いちばん重要な財産”と考えると見えるもの
http://gihyo.jp/dev/serial/01/tdd_supremacy
タイトルと概要しか見てないけど、短かい文章でテストの重要性を言い表わしてるなと思ったんでコピっとく

328デフォルトの名無しさん2014/02/12(水) 14:39:26.47
>>327
コードのインデントやレイアウトがキモ過ぎるし、newしたオブジェクトを=&で代入したり、
もう全く信用できないので、本文も読む価値無いね。

329デフォルトの名無しさん2014/02/12(水) 15:34:30.78
>>328
いい加減、ちゃんと問題点を指摘できるようになろうぜw

330デフォルトの名無しさん2014/02/12(水) 15:38:44.80
>>329
・コードのインデントがキモイ => 最近のコーディング標準知らないんじゃないの
・レイアウトがキモイ => 最近のコーディング標準知らないんじゃないの?静的解析したことないんじゃないの?
・newしたオブジェクトを=&で代入したり => お前いつの時代のPHPerだよ

331デフォルトの名無しさん2014/02/12(水) 15:41:04.76
>>330
いや、そんなことどうでもいいからw
インデントの幅がどうとか言ってるだけじゃん。

332デフォルトの名無しさん2014/02/12(水) 16:00:01.69
>>331
PHPのことあまり知らないんだろうけど、最近はPSR-1/PSR-2/Zend/PEARのコーディング規約に
沿って書くのが普通。
まぁそれを知らないド素人でも、人のコードを見慣れてればあんな酷いコードは書かないだろう。

それに、今時varとかfunction &hoge()とか$fuga =& new Fuga()とかありえないから。

第2回もちょろっと見たけど、あり得ない酷いコードだわ。

333デフォルトの名無しさん2014/02/12(水) 16:04:05.29
>>332
本文読んでないからわかってないんだろう?

> 前回,「これまでの記事で取り上げたコードを,テスト駆動ベースに移行していく」と書きました

これは「これまでの記事で取り上げたコード」だ
昔のコードだって書いてあるだろ。

334デフォルトの名無しさん2014/02/12(水) 16:21:46.58
>>333
へー、第1回と第2回に載ってるコード全てが昔のコードだって言うの?
いくらなんでも古すぎだわ。

335デフォルトの名無しさん2014/02/12(水) 16:32:05.04
PHP のことあまり知らないから他の言語の利用者にもわかるように
説明してくれると嬉しいところなんだけどな
コードレイアウトは技評の Web 記事編集が手を入れないのが悪い

336デフォルトの名無しさん2014/02/12(水) 16:47:05.39
ここにたれ込めばいいと思うよ
http://gihyo.jp/dev/serial/01/php-programming-examination-room

337デフォルトの名無しさん2014/02/12(水) 20:31:31.24
> プログラミングにおいていちばん重要な財産はテストであり,
> 万一コードをすべて失ってしまったとしても,
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
> −この考えを立証すべく,テストとコードの関係を考えます。

この時点で、オレオレテスト駆動
別の名前付ければいいのに

338デフォルトの名無しさん2014/02/13(木) 00:48:59.46
>>337
> プログラミングにおいていちばん重要な財産はテストであり,
これは嘘w
あたりまえだけどテストよりも動くコードの方が重要。

テストコードはあっても今すぐには価値を生み出さない。
今すぐアプリとしては動かないのだから。価値を生み出すのはアプリのコードの方。
テストコードはなくても動くが、アプリのコードはなかったら動かない。

アプリコードからテストコードを生み出すことはできるが、
テストコードがあってもアプリコードは生み出せない。
仮にテストコードからアプリコードを作り出すことが可能だとして
それにかかる時間はどれくらいかかるか。その間テストコードに価値はない。

そしてテストコードからアプリコードを書くのは不可能
なぜなら全てのコードをテストしているわけじゃないから
その主な例がユーザーインターフェースデザイン、
分かりやすく言えばHTMLで作られた入力画面等。
テストコードがあっても使いやすい(同じ品質の)入力画面は復活不可能。

また現実的な問題としてテストコードが全て書かれているという証明はできない。
アプリコードがあるなら当然そこにすべての動作が記述されているが
テストコードは全てあるとは限らない。

あたりまえだけどアプリのコードのほうが重要。

339デフォルトの名無しさん2014/02/13(木) 01:16:10.11
>>338
アプリコードの方が重要って考えは視点が違うだけだからなんとも

そもそもTDDスレとしての突っ込みどころはオレオレテスト駆動であって
そんなアプリコードとテストコードどっちが重要かってところに
そこまでの長文を書いてまで反応する意味が分からない

340デフォルトの名無しさん2014/02/13(木) 02:24:17.12
>>339
反応する意味がわからない?
ただ書いただけだろ?
何か問題が?

それを言ったら、お前がレスする意味がわからない ← どう答える?

341デフォルトの名無しさん2014/02/13(木) 09:57:16.39
プロレスで相手の手の内を出させないままキックだけで勝って俺TUEEEみたいな

342デフォルトの名無しさん2014/02/13(木) 11:04:59.49
おまえら勘違いすんな
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
同じ*品質*のコードといってるんだ
テストが保証するのはコードの品質であってアプリの価値ではない
ましてや同じ入力画面を復活させる事では全くない

343デフォルトの名無しさん2014/02/13(木) 11:22:44.29
ゴミページを擁護してる奴は何が目的なんだ

344デフォルトの名無しさん2014/02/13(木) 13:59:44.58
TDDどうこうよりも、テスト対象のクラスを継承したテストクラスを作って、テスト結果の確認をテスト対象クラスのメンバに設定された値でアサートするというやり方がセンスないわ。

345デフォルトの名無しさん2014/02/13(木) 20:48:44.35
アプリのソースだけ残った場合と
テストコードだけが残った場合

どっちが安価に元の状況に戻せるの?

346デフォルトの名無しさん2014/02/13(木) 20:55:48.07
>>345
リファクタリングしまくる人の場合は、残ったソースをいずれ破棄したり書き直したりしてしまうので、
テストコードだけ残った方が安価なときもある。

TDDはそういう人向けの手法でしょ。

347デフォルトの名無しさん2014/02/13(木) 22:49:05.90
TDDはアプリのソースとかテストコードがどっちが残ると〜とかそういうことを
語るもんではないんだが

348デフォルトの名無しさん2014/02/14(金) 01:07:04.09
おおよそ、テストをどうやって書くかを考えるのが設計になり、
テストをどのように満たすかを考えるのが実装になる。

テストとコードを共に成長させていって開発を進めるのだから、
片方だけ残して、これがテスト駆動開発だ!とか言われると
ゲフンゲフンとなる。

品質との関連性は微妙

349デフォルトの名無しさん2014/02/14(金) 02:07:53.24
>テストとコードを共に成長させていって開発を進めるのだから、
成長が順調に進むのであればテストファーストもコードファーストも大差なく
テストとコードのどちらを先に書くかの順番の違いしかないが、

成長が逆戻りした(コードに修正を加える必要が出てきた)ときに
テストを優先して(テストの中に設計を含めて)コードを大胆に修正できるようにするか、
コードを優先して(コードの中の設計を維持するように)コードの修正量をなるべく少なくするか、

という所に違いがある、という感じか。

350デフォルトの名無しさん2014/02/14(金) 02:10:51.12
>品質との関連性は微妙
実装フェーズが完了した段階ではコードもテストも固まっているから
テストファーストでもコードファーストでも同等の成果物が作成されて
同等の品質が得られているはず、ということなんだろうか、

それとも、実装フェーズではそれなりに動くモノができていればいい、
品質はその後の試験フェーズで高めていく、という考え方なんだろうか。

351デフォルトの名無しさん2014/02/14(金) 10:08:16.40
>>348
> テストとコードを共に成長させていって開発を進めるのだから、
> 片方だけ残して、これがテスト駆動開発だ!とか言われると
> ゲフンゲフンとなる。

誰も本当に片方捨てろなんて言ってない

> テストが無事なら元と同じ品質のコードをもう一度書くことができる。−この考えを立証すべく

って考え方を言ってるんだよ
お前は抽象的な話しが出来ない奴か?

352デフォルトの名無しさん2014/02/14(金) 10:51:38.30
>>351
> > テストが無事なら元と同じ品質のコードをもう一度書くことができる。−この考えを立証すべく
>
> って考え方を言ってるんだよ
> お前は抽象的な話しが出来ない奴か?

これのどこが抽象的な話なんだ?

「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
で、論破。

353デフォルトの名無しさん2014/02/14(金) 11:11:56.77
後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されている
テスト一式があれば、元コードと同等のものを翔かもしれないが、このこととTDDは
一切関係無いね。

354デフォルトの名無しさん2014/02/14(金) 11:31:08.45
>>352
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> で、論破。

論破って…単なる仮説を立てただけだろ。立証してから言ってくれ
そういう分かりやすい最終的な結論だけで話しを進めるたがる事を
抽象的な話しが出来ないっていうんだよ

355デフォルトの名無しさん2014/02/14(金) 11:56:51.72
>>354
> 論破って…単なる仮説を立てただけだろ。立証してから言ってくれ

は?どうみても
「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
は明らかだろ。

> 抽象的な話しが出来ないっていうんだよ

抽象的を辞書で引け、アホ。

356デフォルトの名無しさん2014/02/14(金) 12:45:53.91
>>351
なんであの糞記事を擁護するの?

357デフォルトの名無しさん2014/02/14(金) 12:52:21.25
>>355
> 「テストが無事でも元と同じ品質のコードをもう一度書くことができないときがある」
> は明らかだろ。

明らか言われても論破された気にはなれないよ

ちなみに「できないときがある」の反対は「常にできる」だから該当記事の「〜ことができる」を
反論している事にはならないよ
むしろ同じ事を言っている

> 抽象的を辞書で引け、アホ。

辞書で引いてみたよ
1 いくつかの事物に共通なものを抜き出して、それを一般化して考えるさま。「本質を―にとらえる」
で、だから何?

358デフォルトの名無しさん2014/02/14(金) 14:24:13.22
>>357
言葉遊びして楽しい?
それより、なんであの糞記事を擁護するのか教えてよ。

359デフォルトの名無しさん2014/02/14(金) 14:31:22.73
>>367
ごく限られた条件下(*)においては、テストが無事なら同じ品質のコードを書くことができる
こともあるだろうが、それはテストの大切さとは直接関係ないし、ましてやTDDとは何の
関係もない。

(*)後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されているテスト
一式がある場合。

TDDスレなんだから、このスレの住人は、TDDにおけるテストの大切さはみんな重要だと
思っているだろうし、その他のテストの重要性もわかってるだろう。

その上で、>>327は駄目記事だと言ってるんだが。

360デフォルトの名無しさん2014/02/14(金) 17:22:33.79
>>357
そもそも
>テストが無事なら元と同じ品質のコードをもう一度書くことができる。
なんてことが必要になる状況はめったにない、で論破じゃないかと。

>>359
TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
でよいよね?

361デフォルトの名無しさん2014/02/14(金) 17:32:25.39
>>360
> TDDにおけるテストの重要性は、「同じ品質」ではなく「同じ動作」を求めるため、
> しかもカバレッジ100%の完成したコードではなく実装途中のコードに対して、
> でよいよね?

そんなかんじ。
カバレッジに関しては、C0カバレッジですら100%に満たないよね。
TDDのテストは、その人が十分だと思う分しか書かれない。
そして、そのテストコードをいわゆる「単体テスト」では使わないという人もいる(extremeな人は全捨てするらしい。マジか)。
俺は使うけど。

362デフォルトの名無しさん2014/02/14(金) 22:19:43.22
>>353
そうだな。誰もそこまでのテストは求めていないし、そんなことする気にもなれない。

363デフォルトの名無しさん2014/02/15(土) 00:21:14.85
テストとソースって
たまごとにわとりの関係なの?

364デフォルトの名無しさん2014/02/15(土) 07:15:22.29
たまごが成長すれば、ニワトリになり
そのニワトリが複数個のたまごを生む。
そのたまごがそれぞれ成長し
それぞれがたまごを複数個生む。


テストとソースはこういう関係です。

365デフォルトの名無しさん2014/02/15(土) 09:04:51.54
カバレッジは、ISOとかで必要なところもあるんだろう
あれも結局は認証されたxUnitでテストするらしいが

366デフォルトの名無しさん2014/03/02(日) 15:11:51.03
カバレッジのスレないのでここで。

テストするまでもないコードというのがある。
たとえば変数の初期化関数とか。
こういうのをテストしたってしょうがない。
だけど実行しないとカバレッジは上がらない。

カバレッジ100%を目指しているわけじゃないが
それはカバレッジを上げるために時間がかかりすぎるなら
コストとメリットを天秤にかけてやらなくていいという話なはず。
だから関数呼び出しだけで簡単にカバレッジがあがるならやってもいいではないか?

テストを行わないが関数実行だけはする。これに意味が無いかといえば
そうではなく。それはコードが確実に動くということを証明できる。
スクリプト言語系はスペルミスなど実行しなければエラーを検出できないことがある。

つまりだ。テストを行わないで関数を実行するだけ。というのは気持ち悪いがありなのだろうか?
テストはしていないが、あえて言うなら関数が動くことをテストしているということ。

367デフォルトの名無しさん2014/03/02(日) 15:58:52.16
それは、なしです

368デフォルトの名無しさん2014/03/02(日) 16:30:47.67
実は関数読んでなかったり別の関数呼んでたらどうするわけ?

369デフォルトの名無しさん2014/03/02(日) 17:01:14.12
>367
理由は何ですか?

処理を実行してコンパイルエラーを
実際に見つけられているのです。

370デフォルトの名無しさん2014/03/02(日) 17:46:28.42
>>366はガバレッジとテストの関係について何か壮大に勘違いしてると思う

371デフォルトの名無しさん2014/03/02(日) 18:15:04.54
なにがしかでも作業効率が改善できてるならいいんじゃないの

カバレッジ○○%達成できました!とか言って持ってきたら殴るけど

372デフォルトの名無しさん2014/03/02(日) 19:06:23.64
>>370 >>371
話ちゃんと聞いてね。

テストもカバレッジも目的じゃない。

実行することでコードが確実に動くことが保証される。
たとえば古いバージョンや新しいバージョンで動かないコードを検出できる。

だから実行だけさせることにも、意味はあるよね。

373デフォルトの名無しさん2014/03/02(日) 19:12:20.55
話を聞いてないように見えるのはお前が基本を理解してないか
もしくは説明が下手だからだ

374デフォルトの名無しさん2014/03/02(日) 19:31:34.78
あぁ、わかった。

例外が発生するテストの反対。
つまり例外が起きないテストと考えればいいわけだ。
ということはコードの最後に必ず成功するテストを入れた方がよさそうだ。

375デフォルトの名無しさん2014/03/03(月) 17:40:56.93
>>366
テストは、実際どのように使うのかというドキュメント性があり、また、テストを書くことによって設計が洗練されるということもあるので、ただ実行するだけのメソッドも意味は無くないと思うよ。

376デフォルトの名無しさん2014/03/03(月) 19:28:18.39
書いたら保守せなあかん
簡単に書けるからと書くと、負の遺産になりかねないかも

変数の初期化関数とかは必要だからやってるのであって
それがないと困る箇所が本当は別にあるのではないだろうか
と妄想

てs

378デフォルトの名無しさん2014/04/06(日) 10:39:53.51ID:7IsAfKCx
2つ質問です。
テストを作ってから同じテストを別のオブジェクトにするとき
別のテストをつくりますか?
リファクタリングをするときソースを書き換えてもとに戻せなくならないように
リファクタリングをする前のファイルを保存しておきますか?

379デフォルトの名無しさん2014/04/06(日) 10:44:48.65ID:AUPUS+0I
>>378
たいていのテスト環境にテストコードの再利用の仕組みはあると思うけど。

バージョン管理しろよ。

380デフォルトの名無しさん2014/04/24(木) 16:15:35.14ID:Vet88S2u
DHH(Ruby on Railsの作者)の"TDD is dead. Long live testing." (の訳)
http://d.hatena.ne.jp/yach/20140424#p1

381デフォルトの名無しさん2014/04/24(木) 17:32:03.50ID:29x10p2Y
彼らは自分のエゴを満たすためにコードを書いてるんだから、
金色の牛を殺したりしたらダメだよね?(´・ω・`)

382デフォルトの名無しさん2014/04/25(金) 16:52:52.53ID:TjzC2Fyr
>>380
一行目から引いた

383デフォルトの名無しさん2014/04/28(月) 12:40:27.17ID:97z81I41
Unit Test Frameworks
よんだけど、CPPUNITのことが全然書いてないので
CPPUNITの高度な使い方ってどうやってわかりますか?

384デフォルトの名無しさん2014/04/28(月) 15:56:01.02ID:GLzPd+IX
>>383
> Unit Test Frameworks
これ何

385デフォルトの名無しさん2014/04/28(月) 15:59:59.35ID:97z81I41
UnitTestFrameworks.pdf?

386デフォルトの名無しさん2014/04/28(月) 16:19:09.38ID:GLzPd+IX
つか、CppUnitの高度な使い方って何よ?

387デフォルトの名無しさん2014/04/28(月) 16:20:09.84ID:GLzPd+IX
>>385
> UnitTestFrameworks.pdf?
何それ?何かの海賊版か?

388デフォルトの名無しさん2014/04/28(月) 16:23:45.04ID:97z81I41
抽象クラスのテストを作って派生クラスのテストでテストしたいクラスを初期化する方法とか。

389デフォルトの名無しさん2014/04/28(月) 16:24:20.94ID:97z81I41
UnitTestFrameworks.pdf
で検索すると出てくる著作権フリーの書籍。

390デフォルトの名無しさん2014/04/28(月) 16:27:49.28ID:GLzPd+IX
>>388
ちゃんとわかる文章書け。
つか、ほんとにそれ「CppUnitの高度な使い方」に関する疑問なのか?

391デフォルトの名無しさん2014/04/28(月) 16:29:49.62ID:GLzPd+IX
>>389
> UnitTestFrameworks.pdf
> で検索すると出てくる著作権フリーの書籍。
なんでずばっとURL書かないの?
俺が検索したら、O'REILLYの奴しか見つからなかったが。
これ、フリーじゃないだろ。

392デフォルトの名無しさん2014/04/28(月) 16:30:35.56ID:97z81I41
>>391
O'REILLYはフリー

393デフォルトの名無しさん2014/04/28(月) 16:34:49.54ID:GLzPd+IX
>>392
まさか、DRMフリーの意味がわからんのか?

394デフォルトの名無しさん2014/04/28(月) 16:46:40.37ID:sLIIqVQo
PDF の各ページのフッタ見ればわかるけどフリーで配布されてるわけじゃないね

395デフォルトの名無しさん2014/04/28(月) 16:51:24.25ID:97z81I41
なんかの記事で見たけど、無断配布を禁止するより
しない方が本が売れるからわざとそうしてるらしい。

396デフォルトの名無しさん2014/04/28(月) 16:56:55.25ID:GLzPd+IX
>>395
> なんかの記事で見たけど、無断配布を禁止するより
> しない方が本が売れるからわざとそうしてるらしい。
どこの記事だよ?
O'reillyはDRMはフリーにしたけど、無断配布は禁止だろ。

397デフォルトの名無しさん2014/04/28(月) 20:05:02.12ID:2i2SR7ZO
なんだ釣りか

398デフォルトの名無しさん2014/04/29(火) 10:12:01.42ID:gWfSfq0v
別にDRMフリーって無料配布を禁止してないわけじゃないんだけどなw

399デフォルトの名無しさん2014/04/29(火) 10:15:16.74ID:FmOJz83e
A. オライリー・ジャパンが販売する書籍(Ebookも書籍だと考えています)は、
コピー・フリーではありますがコピーライト・フリーではありません。
日本国の著作権法による保護を受けており、
著作権法で定められた範囲を超えた複製、頒布、
送信などは、
著作権法に抵触する恐れがありますのでご注意ください。

400デフォルトの名無しさん2014/04/30(水) 12:43:00.88ID:4gXDKzV2
著作権フリーだの無断配布だの意味不明な俺用語でかたるのがおかしい

401デフォルトの名無しさん2014/05/08(木) 10:55:00.04ID:7mqxxUyE
> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

正しい理解が為されればTDDがdisられないという考えがすでに宗教。
だから原理主義言われるんだよ。

402デフォルトの名無しさん2014/05/08(木) 13:18:58.75ID:QEfRwn3W
そうだな
TDDという概念自体が完全に誤ったもの
動いてるコードに手を触れないことこそが真理

403デフォルトの名無しさん2014/05/08(木) 23:11:10.80ID:o3vM5nSH
>>402
君、概念以前にTDDが何なのかすらよく分かってないでしょ

404デフォルトの名無しさん2014/06/14(土) 11:06:05.15ID:7s4E5mM1
うんこ

405デフォルトの名無しさん2014/07/21(月) 15:26:18.47ID:f2PpmiaZ
オウンコ

406デフォルトの名無しさん2014/07/21(月) 15:27:39.55ID:SvZi82X8
マンコ

407デフォルトの名無しさん2014/08/06(水) 12:12:57.58ID:B/o+YfUv
テスト鳥文

408デフォルトの名無しさん2014/08/19(火) 01:55:15.38ID:TPeuIISX
とりぶん?

409デフォルトの名無しさん2014/09/29(月) 15:59:03.19ID:PXDdRZQD
なぜ流行らなかったスレが死滅したな

410デフォルトの名無しさん2014/09/29(月) 22:02:10.49ID:QcGUG2KQ
あのスレのカオスっぷりを見れば
なぜ流行らなかったのか良く分かる

411デフォルトの名無しさん2014/09/29(月) 22:59:57.93ID:yt38cp2j
2ちゃんねらーの脳みそではテストなんて書けるわけがなかったってことだ

412デフォルトの名無しさん2014/09/30(火) 08:06:51.52ID:76NHBRqV
TDDはともかくユニットテストまで否定かよ
恐れ入る

413デフォルトの名無しさん2014/10/01(水) 16:56:59.90ID:+PWQCZCn
TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。
あと、自分の嫌いなスクリプト言語をわざわざdisりに行く奴とメンタルが似てる気がする。

414デフォルトの名無しさん2014/10/01(水) 17:01:54.48ID:YKNuKmx4
自己紹介ですね
わかります

415デフォルトの名無しさん2014/10/01(水) 22:34:56.80ID:0wPPS909

416デフォルトの名無しさん2014/10/02(木) 14:30:41.58ID:Ob3tDv0H
>>415
http://blog.fieldnotes.jp/entry/2014/05/07/225129

> DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を
> 呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視
> した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。

417デフォルトの名無しさん2014/10/02(木) 14:37:04.66ID:Ob3tDv0H
あとこれも追加。

【翻訳】TDD is Fun
http://diskogs.hatenablog.com/entry/2014/04/25/085112

418デフォルトの名無しさん2014/10/02(木) 21:31:51.50ID:cEl3U7zN
>>416
そのリンクを出して何を言いたいのか分からない
もう一回>>413>>380を嫁

419デフォルトの名無しさん2014/10/03(金) 11:17:58.55ID:MGOEkXEo
>>418
えっとね、>>380>>413も書いたの俺なんだわ。
逆にお前が何を言いたいのかわからんわ。

420デフォルトの名無しさん2014/10/03(金) 23:03:06.98ID:PD4heIQt
>>419

>>413
> TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。

>>380
> http://d.hatena.ne.jp/yach/20140424#p1
> TDDには感謝しているが、設計の教義としてはとっくに使わなくなっている。

とっくに使わなくなっている=現場で使えない=否定 だよね

421デフォルトの名無しさん2014/10/06(月) 10:30:55.78ID:auIRFVse
>>420
アスペなの?
俺が言ったのは傾向だよ。

422デフォルトの名無しさん2014/10/06(月) 22:45:50.57ID:h87PXXn5
TDDは慣習

423デフォルトの名無しさん2014/10/12(日) 02:49:57.49ID:Go9nxJDi
組み込みなんだが

実機とTDDの解析環境でコンパイラが別になる

こういう場合は何をもってテストしたといえるんだ?

424デフォルトの名無しさん2014/10/12(日) 10:48:18.63ID:0nnSDdGO
気になるのはコンパイラが別になるってことだけ?
それなら解析環境(?)でテストがパスすればテストしたと言えるだろう

コンパイラの差異については結合テストとシステムテストをパスすれば
問題ないと考えていいんじゃないの

425デフォルトの名無しさん2014/10/12(日) 11:10:47.48ID:LjQH95WZ
最適化のバグでひどい目に遭ってからそのへんの互換性は信用出来ないと思い知ったわけだが
それでもテストしないよりはマシ

426デフォルトの名無しさん2014/10/12(日) 15:18:45.36ID:Go9nxJDi
>>424
他にも色々ある

というか俺の職場の装置のソースがクソなんだろうけど
パラメータが多すぎて全部網羅するのは無理

TDDでいうテストってのはどういうイメージなのか
ネットや本を見てもピンとこない

x+1の関数に1をいれて2になりましたとか
そんな説明は求めてないのだが

427デフォルトの名無しさん2014/10/12(日) 21:43:25.28ID:0nnSDdGO
>>426
TDDがどんなものか、何の略かまでは分かる?
クソなソースになっているのならどうしようもないだろう

それにパラメータ多すぎて全部網羅するのは無理っていうけどさ
TDD以前にカバレッジはどうすんのよ

組み込みでC0すらパスしないような状況になってたらかなりマズイ気がするが

428デフォルトの名無しさん2014/10/12(日) 22:13:02.74ID:tcHpyVOC
>>426
TDDで目指すのは小さなフィードバックループを作ること
開発者が安心を得つつコーディングできること
安心というのは、ここでいうと例えば「実機で確認されていないコード・機能をベースに、それに依存したコードをさらに積み上げていくこと=不安な状態」的な

何をもってTDDでいうテストとなるか、って定義は割とどうでもいい気がする
>>423の環境で何をどうすれば開発者が安心できるか、作業のループを小さくしてフィードバックを得られるか、が大事
「これが動けばこのコードは正しい」っていう一般的なテストがあって
それが自動化できてさらにフレームワークで成否確認までできるなら十分
そうでないなら何か妥協したテストでやるしかない

・実機と検証(解析?)環境がどの程度異なっていて、開発者は検証環境をどの程度信頼できるのか
・どの程度の頻度で実機テストができるのか
とかが重要なのでは?
ここらへんは現場を見てないので多分他人には分からない所。

仮に検証環境があまり信頼できないのであれば、そこだけでどれだけ完璧な開発プロセスをこなしてもムダになる危険性が残るだろうから
実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
そうすると一般的なTDDは実践しづらくなると思う。
けど実機でのテストを自動化できるのであれば多少は導入できるかも?

組み込みとか知らんのでとんちんかんなこと言ってたらすまん

429デフォルトの名無しさん2014/10/13(月) 10:22:06.70ID:eF/9rJ3u
>>428
ありがとう

指摘はとても現実を捉えていて救われた思いがした

現実は顧客の装置の一部のデバイスを作ってるのだけど
検証環境が貧弱(または無い)ので
仕様変更箇所のみを検査するみたいな対応になってしまってる
ここ数年リストラで人減りまくったのと
士気の低下なのかテスト不足と思われる市場不良が多発


「安心」と言う意味では
徹底的な回帰テストをすることが大事だとおもう

問題はどうやってそれをやるかなのだけど

430デフォルトの名無しさん2014/10/14(火) 11:44:30.46ID:+LKn0wPu
>>428
> 実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
> そうすると一般的なTDDは実践しづらくなると思う。
組み込みの種類にもよるだろうけど、対象物をmock(あるいは、シミュレータ)で作って
実機なしに開発・テストできるようにするのが、自動テストをやる派の中では一般的だと思う。

まあ、中には「現地に行かないと、プログラムの起動すらできないのでテストできません」とか
言う奴もいるんだが。

431デフォルトの名無しさん2014/10/15(水) 22:41:20.51ID:2mUB6yWE
UARTなりCANなりイーサネットなり
この部分は完璧に通信できるものとして実装するでおk?

432デフォルトの名無しさん2014/10/16(木) 10:27:00.84ID:qnIoh31O
エラーのシミュレーションはするべき

433デフォルトの名無しさん2014/10/16(木) 13:38:30.32ID:6zTGqYum
異常系の仕様が定義されていればそれに対応する
それ以外は単体テストの範囲ですらない

434デフォルトの名無しさん2014/10/16(木) 13:56:42.86ID:+afjrAmT
>>433
定義あるいは明示されていない異常が発生して鼻から悪魔が出ても、それは俺のせいじゃないから
問題ないという主義ですか?

435デフォルトの名無しさん2014/10/16(木) 17:14:14.25ID:CsOFEKWu
まるで公務員の主張だな

436デフォルトの名無しさん2014/10/16(木) 19:29:56.64ID:z4r7htJV
一緒に仕事したくねーな

437デフォルトの名無しさん2014/10/16(木) 21:49:07.00ID:6zTGqYum
縦割りはそういうもの

438デフォルトの名無しさん2014/10/17(金) 01:41:12.71ID:QJMYKMHi
担当者が設計と開発で分かれているなら>>433が正しい

開発の見積もりは「この仕様(設計書)通りに作ったら○○人月」で算出してるわけで
「異常系に漏れがないかチェックしろ、漏れてたら仕様に書いてなくても対応しろ」は
見積もり範囲外の作業だよ

予算が潤沢に貰えるなら「サービス」で対応するかもしれないが
そんなに潤ってるプロジェクトは滅多にないだろう

439デフォルトの名無しさん2014/10/17(金) 10:40:07.93ID:yP2f7CgA
>>438
設計する人は、たとえばファイルに保存するときに起こり得るエラー原因ごとにどう対処すべきかを
網羅したりするんですか?

440デフォルトの名無しさん2014/10/17(金) 11:21:29.10ID:HZvg3la9
printf() の戻り値見ろと言っているに等しい

441デフォルトの名無しさん2014/10/17(金) 15:20:26.07ID:bxyVopED
>>439
必要なら処理中の突然の電源断やディスクやメモリの破損なんかも網羅するよ
必要か(現実味があるか)どうかを切り分けるのが仕事だよ

442デフォルトの名無しさん2014/10/17(金) 16:05:39.88ID:yP2f7CgA
>>441
ちょっと議論するのめんどくさいんだけど、開発者の裁量内で判断する異常処理ってないのという疑問なんだけど。
そういう判断を一切する必要がない開発者は、エンジニアやプログラマとは呼ばずに、コーダーやパンチャーって呼ばれると思うんだけど。

443デフォルトの名無しさん2014/10/17(金) 22:32:13.59ID:i/Kzfu5g
>>442
たとえ一人でやっている場合でも、アーキテクチャ(何が起きるか)と、
インプリメンテーション(どう起こすか)は明確に分けるべき。
ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。

少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
に"何が起きるか" は、アーキテクチャとして定義されなければならない。

どちらが、より創造的かということには意味はなくて、単に別の仕事。

444デフォルトの名無しさん2014/10/17(金) 22:37:06.62ID:i/Kzfu5g
TDD (BDD) には、インプリメンテーションをやるまえに
テストケースを作ってアーキテクチャを確認しようぜ
という意味も有る。

445デフォルトの名無しさん2014/10/18(土) 00:53:05.90ID:o6ZdOp19
そりゃプログラマだってアホじゃないんだから要件漏れ気づくこともあるよ
テストを作成していて漏れに気づくことだって多いしね

ただしそれを見つけたり直したりするのはプログラマの役目ではないし責任もない
優秀なプログラマなら「○○処理が漏れてますよ」と指摘だけして
どうしますか?対応するなら再見積もりしますね?で予算をふんだくる

446デフォルトの名無しさん2014/10/18(土) 12:25:58.33ID:/bV95tiS
なるほど

447デフォルトの名無しさん2014/10/18(土) 15:13:02.82ID:mzkaImX0
>>445
あんた公務員か

448デフォルトの名無しさん2014/10/18(土) 15:19:28.52ID:r/p1CvCN
たぶんプログラマって言葉の定義が違うんじゃね
SE/PG世界のプログラマは普通のプログラマと別の概念

449デフォルトの名無しさん2014/10/18(土) 15:52:52.83ID:2d9yKbqY
>>439
Javaの例外は3種類あって、
プログラマが主に想定する例外は、Exception

Error
メモリ不足やハードウェアの故障など、
プログラムではどうにもならないもので、catchする必要がない

Exception
ファイルが読み書きできない、ネットワークがつながらないなど、
プログラムで想定できるもので、catchすべき

RuntimeException
NullPointerのチェックなど、
一々想定していると切りがないもので、catchしなくてもよい

450デフォルトの名無しさん2014/10/18(土) 16:24:30.31ID:L9rzpY5S
アーキテクチャをそんな意味で使うの初めて見た

451デフォルトの名無しさん2014/10/19(日) 00:06:51.41ID:GulnFHAj
>>440
> printf() の戻り値見ろと言っているに等しい

例外がない言語はそうなるから大変なんだよね。

例外がある言語ならすべての行でエラーが起きる可能性がある
という前提でプログラムしても全然負担にならないのに。

452デフォルトの名無しさん2014/10/20(月) 11:17:44.91ID:MhItlF5V
>>443
> たとえ一人でやっている場合でも、アーキテクチャ(何が起きるか)と、
> インプリメンテーション(どう起こすか)は明確に分けるべき。
> ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。
ちょっと俺とは「アーキテクチャ」の使い方が違うようだ。

> 少なくともユーザに仕様として提示されるものは、全てアーキテクチャなんで、
ユーザに仕様として提示すべきものは「外部仕様」。
そして、その中には内部で使用するアーキテクチャは明示されるかもしれないし、明示されないかもしれない。

> 必要なファイルが無かったり、外部装置や EAI の接続先が故障していた場合
> に"何が起きるか" は、アーキテクチャとして定義されなければならない。
内部設計では、何が起きえて何をすべきかを網羅することは必要だが、外部仕様としてはそれらをすべて
含む必要はない。

453デフォルトの名無しさん2014/10/21(火) 17:54:15.96ID:LMlVzSKe
コードを書かない?設計者が、最終的に使用するミドルウェア・ライブラリ・APIに精通してる奴多すぎ。
んで、if (エラー条件)となる部分を全部設計書に明記するだって?
どんだけ分厚い設計書なんだよ。

454デフォルトの名無しさん2014/10/21(火) 17:56:11.27ID:LMlVzSKe
>>451
> 例外がある言語ならすべての行でエラーが起きる可能性がある
例外がありゃあったで、別に考えないといけないことも増えるんだけどね。

455デフォルトの名無しさん2014/10/22(水) 01:30:09.07ID:S8JTP3B8
>>453
冗談と思うかもしれないが、開発を海外に投げるときは
それくらいしないと酷いことになる

456デフォルトの名無しさん2014/10/22(水) 10:11:18.50ID:d0Ctl7Dm
>>455
オフショアの話なんて誰もしてないと思うが

457デフォルトの名無しさん2014/10/22(水) 12:52:41.64ID:G2nqW3Ft
>>455-456
わかるわ
日本人同士で日本語で会話しててもこうだもんな

458デフォルトの名無しさん2014/10/22(水) 13:54:32.30ID:d0Ctl7Dm
>>457
何を言いたいのかさっぱりわからん
確かに日本人同士でも話が通じることはまれかもな

459デフォルトの名無しさん2014/10/22(水) 18:54:17.18ID:LJFjeu5w
>>444

既に存在するスパゲティなCのプログラムがあるんだけど

これをテストしようとおもうんだが
どうしたらいいとおもう?

ちなみに全てのcファイルが
そのほかのcファイルのヘッダを全部インクルードしてて
隠蔽もクソもない。外部参照の鬼状態で
スタブを作るだけで気が遠くなりそうな状態

460デフォルトの名無しさん2014/10/22(水) 19:01:41.56ID:11jX6UQ8
テストの使い方を間違ってる

461デフォルトの名無しさん2014/10/22(水) 19:16:11.80ID:wZt8Yc67
レガシーコード改善ガイド

462デフォルトの名無しさん2014/10/23(木) 13:10:10.45ID:YQ33Y8kR
>>459
> そのほかのcファイルのヘッダを全部インクルードしてて
まずここから改善していけば?

463デフォルトの名無しさん2014/10/23(木) 13:42:02.91ID:eDVkHXcG
よくよく見てみたら相互参照や循環が2〜3箇所で
それを除いて解きほぐしたら案外単純…ってことが多いんじゃないかな

464デフォルトの名無しさん2014/10/24(金) 01:19:22.31ID:ytrFsh/0
実装済みならE2Eテスト書けば

465デフォルトの名無しさん2014/10/25(土) 23:02:32.16ID:vC010Lko
スパゲティ

466デフォルトの名無しさん2014/11/08(土) 12:34:57.35ID:EW+rnnAz
パスタ

467デフォルトの名無しさん2014/11/09(日) 12:21:49.68ID:yjLcynWs
テスト駆動ってC0カバレッジの確認しづらくない

468デフォルトの名無しさん2014/11/09(日) 20:05:25.41ID:45yI7iTj
最後に確認して足りなきゃ足したら良いんじゃないの?

469デフォルトの名無しさん2014/11/09(日) 20:47:28.67ID:dsC9nPzL
お前はなんにもわかってない

470デフォルトの名無しさん2014/11/09(日) 20:56:21.42ID:iKzDg9OD
まさかC0を通すためにテストを書き直すとかやってるんじゃないだろうな・・・

471デフォルトの名無しさん2014/11/16(日) 09:33:56.00ID:ZyAZKYiT
>>470

TDDは開発手法だよ。
TDDと品質テストは、別物として考えるべき。これって、教科書の2,3ページくらい目に書かれている。

ただ、TDDのテストも品質テストに流用は可能だ。なので >468は良くわかっている人間だ。

472デフォルトの名無しさん2014/11/16(日) 10:04:32.62ID:chCKawZi
>>471
なんで俺にレス付けたのか知らんがそんなの知っとるがな

4734592014/11/22(土) 19:34:49.92ID:Le0NeUvk
>>462
職場の製品プログラムなんで
末端の俺ごときがインクルードをいじると鬼のように罵倒される


なのにカバレッジテストの業務ルールを作れといわれたんだが
正直テストケースを書くだけで眩暈がする
境界値テストとかもはや不可能

474デフォルトの名無しさん2014/11/22(土) 19:48:51.79ID:2zfZYN6C
罵倒されるような人間にルール作りを任せる? ありえんわ
出来ても誰も守らねーだろう
適当に作っとけよ

475デフォルトの名無しさん2014/11/22(土) 19:56:54.71ID:2zfZYN6C
一応フォローしておくと>>473が悪いわけじゃない
依頼した上司が無能ってことだ

TDDに限ったことじゃないがルールは運用に乗せてこそ意味がある
権限の無いヤツにルール作らせたって回せるわけがない

476デフォルトの名無しさん2014/11/23(日) 14:05:47.05ID:YQdbMQXk
473-475は無能

477デフォルトの名無しさん2014/11/23(日) 14:26:41.19ID:GCb4Xc58
476がスゲー解決策を提示してくれるようです

478デフォルトの名無しさん2014/11/25(火) 11:06:37.29ID:S6K9qD6w
>>459
> そのほかのcファイルのヘッダを全部インクルードしてて
というのが、「その他の.cファイルがインクルードしてるファイルを、全部インクルードしている」という
意味なら、不要なインクルードファイルを削るのは何も問題がない(問題があればビルドできない)し、
メンテナンスコストが下がるという大きなメリットがある。

>>473
> 末端の俺ごときがインクルードをいじると鬼のように罵倒される
というような理由付けで上長(?)を説得できないほどの低レベルな職場なら、辞めてしまったほうが
いいんじゃないか。

479デフォルトの名無しさん2014/11/25(火) 23:45:47.25ID:Nxen9kpa
使ってないincludeをコメントアウトしただけで動かなくなることもあるからなぁ
末端のPGが勝手にいじるのもどうかと思うよ

組み込みとか古いプログラムだとよくあるんだよね
メモリ周りにバグがあって偶然動いているようなプログラムは
参照を外しただけでアドレスが狂って動かなくなる

480デフォルトの名無しさん2014/11/26(水) 19:32:04.26ID:iN5Oa4ie
組み込み系のひとが書くCなんてめちゃくちゃだよ

481デフォルトの名無しさん2014/11/27(木) 10:10:09.22ID:r+bsdp9/
>>480
それ単にその人がレベルが低かっただけじゃないか。
組み込み系の組織では、MISRA-Cを意識してるとこ多数だよ。

482デフォルトの名無しさん2014/12/22(月) 15:36:54.08ID:lSyDhRKu
組み込み系が酷くなかったいう話は聞いたことがない
自分たちはちゃんとやってるつもりだったのか

483デフォルトの名無しさん2014/12/22(月) 17:25:12.55ID:xehSPM0d
組み込み系が酷いということなら、業務系も酷いぞ
ゴミの寄せ集めだし

484デフォルトの名無しさん2014/12/24(水) 00:40:32.72ID:83J9p+C4
酷い方向が違うんだよな。
どっちも酷いのは多い

485デフォルトの名無しさん2014/12/25(木) 01:35:17.73ID:QeaHxHUz
組み込みや業務系が酷いと言われるのはライフサイクルが長いからだよ

それ以外のプロジェクトも実際はゴミばっかり
だけどそれが顕在化する前に淘汰されてサービスの終了を迎えてるってだけ

486デフォルトの名無しさん2014/12/31(水) 16:18:59.05ID:y3Bru/20
組み込みが酷いのはハードやコンパイラの制約によるもの
業務系が酷いのは要員のレベルのばらつきの大きさによるもの

487デフォルトの名無しさん2014/12/31(水) 16:49:50.16ID:eUm/9QT3
組み込みも要員のレベルとさせてくれ
環境があるのに頑なに適応せずに昔のままをやりたがる

488デフォルトの名無しさん2014/12/31(水) 16:55:18.42ID:vA2dnFSZ
>>487
ハード完成してなくてI/F仕様書もレビュー通ってないけどこれで実装お願い!
開発環境? ベストなものをお願いします!
って言われたことある?

489デフォルトの名無しさん2014/12/31(水) 17:19:00.28ID:JkDgdJ7S
>>488
ある、キーボードぶん投げた希有な事例だった。
割とマジで開発馬鹿にすんなゴルァって部長ですらぶち切れてた

490デフォルトの名無しさん2014/12/31(水) 17:36:35.58ID:5tzGTAD9
ソフト屋さんが仕様決めて!その通り作るからってのはあったな
おまえ回路図で線繋ぐだけかよって…
ハードのデバッグもソフト屋まかせな奴だったのでキレました

491デフォルトの名無しさん2015/01/03(土) 22:02:59.55ID:kkg062go
亀レスだけど

>>481 組み込み系の組織では、MISRA-Cを意識してるとこ多数だよ。
MISRA-C て本当にまともなルール仕様か?

下を見て、こりゃ阿呆だと思っている。
20.7 R setjmpマクロ及びlongjmp関数は、用いてはならない。

492デフォルトの名無しさん2015/01/04(日) 00:56:12.46ID:inwAoRSs
下手な使い方して落とし穴掘られるリスクより
ハングさせてハードリセットする方がマシというケースも多い

493デフォルトの名無しさん2015/01/12(月) 00:20:00.80ID:qplG+w6a
でテスト駆動ってどうなのよ

494デフォルトの名無しさん2015/01/12(月) 00:22:31.65ID:qWf800EE
終わった

495デフォルトの名無しさん2015/01/12(月) 08:58:02.07ID:bBlSgM6z
テストなんて書くだけ無駄
コードとテストで仕事が2倍になるだけ
どうせ一回通ったら用済みなんだから書く必要ない

496デフォルトの名無しさん2015/01/14(水) 20:01:04.12ID:mbeKC74a
TDD by example 再出発

497デフォルトの名無しさん2015/01/14(水) 21:26:18.53ID:ZzJLW/vD
>>495
じゃあテスト仕様を先に作るだけなら問題ないの?

498デフォルトの名無しさん2015/01/18(日) 07:54:29.17ID:AOSxsRns
yes

499デフォルトの名無しさん2015/01/18(日) 09:12:40.34ID:geB77wKJ
一回通ったら用済みとか言ってる時点でまともな開発やったことない奴だってわかる

500デフォルトの名無しさん2015/01/18(日) 10:11:14.89ID:sNaTaheH
そんな香具師と判ってて相手するとか
どんだけ親切なんだ

501デフォルトの名無しさん2015/02/21(土) 16:03:21.19ID:FlDtTMp/
むしろテストが一度でも行われていたらラッキー

502デフォルトの名無しさん2015/02/22(日) 14:32:31.50ID:J+2bP69K
どっかのSEを自称するひとがW字開発とか意気込んでたけど
これもテスト駆動ってやつ?

503デフォルトの名無しさん2015/02/22(日) 16:00:00.52ID:WbEMx951
違うんじゃね

504デフォルトの名無しさん2015/02/23(月) 21:53:44.54ID:YPq7I/CP
w字開発は悲劇の開発

505デフォルトの名無しさん2015/02/23(月) 22:53:58.10ID:wIOqQNws
W字って初めて聞いた
仕様変更や手戻りが発生したら大変そうなんだけどどうなの

506デフォルトの名無しさん2015/03/05(木) 20:35:18.19ID:Z1VFzrPe
仕様変更の度に試験仕様書の修正が発生します

507デフォルトの名無しさん2015/03/05(木) 21:41:49.24ID:K2/AKKmr
仕様変更という言葉の意味を知った上で言ってるのか

508デフォルトの名無しさん2015/03/06(金) 01:16:33.41ID:dcg9agNJ
メタテストですね

509デフォルトの名無しさん2015/03/07(土) 20:16:06.24ID:lexZIoDv
>>507
何か変か?
仕様決める→テスト仕様書作成→プログラム設計→コーティング
なんだから仕様が変わる度にテスト項目見直しだろ

510デフォルトの名無しさん2015/03/07(土) 20:48:33.06ID:evNQRu0c
>>509
変だろ
なんでそんな当たり前のことを述べる必要があるんだ
それとも>>506には何か深い意味があるのか?

511デフォルトの名無しさん2015/03/16(月) 21:05:40.30ID:OhH2Zqat
テストプログラムのテストというのはおかしいでしょうか。

例えば、アクションゲームの自動機能テストを行うために、
予め設定した大まかな指示通りに自動でコントローラーを入力する
仮想的なプレーヤーをプログラムしたとします。

このプログラムはゲームのリリースには含めないテストプログラムのひとつです。
しかし、正しく動くことが明らかなほどシンプルなプログラムではありません。
なので、この仮想プレーヤープログラムもテスト対象とすべきだと私は思います。

このような考え方はテスト駆動開発としては間違っているでしょうか。


テスト駆動を解説した本やWeb記述にもこのような状況のことは書かれていないような気がします。

512デフォルトの名無しさん2015/03/16(月) 23:22:18.02ID:iyRDLNI5
>>511
テスト駆動の考え方がわかってないだけ

513デフォルトの名無しさん2015/03/17(火) 17:20:27.93ID:Bw8e4yLM
テストプログラムのテストのテストというのはおかしいでしょうか。
テストプログラムのテストのテストのテストというのはおかしいでしょうか。
テストプログラムのテストのテストのテストのテストというのは可笑しいでしょうか。

514デフォルトの名無しさん2015/03/17(火) 18:34:03.30ID:vCwecCoL
>>511
> テストプログラムのテストというのはおかしいでしょうか。
別におかしくないが、そのこととTDDとは何の関係もない。

5155112015/03/17(火) 19:28:49.00ID:FrSWu1Dj
>>512
>>514
わかりました。
ありがとうございます。

516デフォルトの名無しさん2015/03/17(火) 23:32:04.19ID:c2oAi75i
意外と>>513が正しいのでは

517デフォルトの名無しさん2015/03/17(火) 23:38:56.12ID:k/LbPUX+
>>516
数学的に考えれば品物が上がらない事は明白だろう?

518デフォルトの名無しさん2015/03/20(金) 15:48:44.47ID:4UXRNT4S
どこまでテストするかの話になると外部ライブラリだけでなくコンパイラやOSまで疑う必要がある
一昔前のコンパイラは多すぎてコンパイラのテストもやっていたな

5195182015/03/20(金) 15:51:36.12ID:4UXRNT4S
訂正
>一昔前のコンパイラは多すぎてコンパイラのテストもやっていたな
一昔前のコンパイラはバグが多すぎてコンパイラのテストもやっていた

520デフォルトの名無しさん2015/03/31(火) 18:51:00.25ID:855buxIJ
Kindleでこんな本が発売されたのを発見。
読んでないので内容は全くわからないが、目次を見る限り、よさげな気もする。

『これからはじめるTDD テスト駆動開発入門 (Think IT Books)』 \1,400
http://www.amazon.co.jp/dp/B00VFQ7WCM

> エクストリーム・プログラミングのプラクティスのひとつであるテスト駆動開発(TDD)について、
> 聞いたことはあるけれど内容は知らない方、概要は知っているけれど実際に使ったことが
> ない方を対象に、全7章にわたってご説明していきます。アジャイルをかじった程度の開発
> 経験の浅いプログラマと、TDD開発を実践しているプロジェクトリーダーによる会話形式で
> 楽しくTDDを学びましょう。本書は、インプレスが運営するWebメディア「Think IT」で、「マル
> チプラットフォーム対応のゲーム開発エンジンUnityを体験する」として連載された技術解説
> 記事を電子書籍およびオンデマンド書籍として再編集したものです。

521デフォルトの名無しさん2015/03/31(火) 21:27:32.21ID:D90KPxNw
ステマ乙。目次どこにあるんだよ。

522デフォルトの名無しさん2015/03/31(火) 21:42:50.98ID:D90KPxNw
あとUnityどこに関係するんだ?amazonの紹介文修正しとけよ。

523デフォルトの名無しさん2015/04/01(水) 10:34:19.69ID:MxSupW0l
>>521
TDDの本なんてめったに出ないから紹介しただけだし。
目次は
http://book.impress.co.jp/books/1114170210
にある。
俺はTDD初心者じゃないから買わないけど。

5245232015/04/02(木) 10:30:42.33ID:DnwfhgCI
ステマ言われたんで買ってみた。
40分で2/3位読めた(コード入力してないから)。
内容はTDDを全く知らない人向け。誤植を何カ所か見つけた。
DHHのTDD is deadについても言及があるが、及び腰で全くなってない。

5255232015/04/03(金) 13:21:39.26ID:C7O2gbfJ
読み終わったけど、全然駄目だった。
やはり、自分が読まないとお薦めしてはいけないね。

筆者は、TDDをテスト手法でもあると勘違いしてる気がする。

誤った要件理解をTDDのテストがFailすることで発見する場面が何度か出てくるが、
TDDでテストがFailするのは、基本的に最初にテストを実装・実行するときと、自分の
意図したものが正しく実装できなかったか、あるいは、リファクタリングで何かを壊した
ときかのどれか。
まあ、期待値が間違ってたということもあるけど、それは要件を間違って理解したと
いうことではない。

この本の例に則して言えば、例えばボーリングで一投目から、{(3, 7), (G, 3)}と投げた
ときのスコアを13点ではなくて16点だと誤った思い込みをしたとき(期待値を間違った
わけではなくて、スペアのボーナスは、次に初めて獲得した点数だと思い込む)、
TDDというはその誤った思い込みによるスコア体系を正しく実装する手段でしかない。

526デフォルトの名無しさん2015/05/29(金) 14:19:57.76ID:McOxVkvH
TDDを行った時にぶつかった7つの壁
http://qiita.com/syou007/items/7d6fdf1b7b6245a07bce

527デフォルトの名無しさん2015/05/29(金) 15:10:31.84ID:McOxVkvH
TDDに関する議論をググってみて見つけたページ。

TDDをめぐる、最近の議論についての私見。
http://blog.fieldnotes.jp/entry/2014/05/07/225129

完全に同意。
TDDは、
> 開発者テストのレベルで「開発者の思ったとおりに動く」ことが保証
されるようにするもの。
そしてそれを使って
> テストによって開発が駆動されること
を目指すもの。

528デフォルトの名無しさん2015/06/01(月) 10:17:17.81ID:4t8ilUI7
>>526
TDDと、品質保証のための自動テストによる単体テストを、完全に混同してる。

529デフォルトの名無しさん2015/09/23(水) 22:50:15.66ID:nPFFi/Oi
qiitaにマジレス

530デフォルトの名無しさん2015/09/29(火) 22:12:17.46ID:diX6sJrx
テスト駆動開発はゴミクズ

531デフォルトの名無しさん2015/11/26(木) 08:24:06.20ID:Dizh+t9P

532デフォルトの名無しさん2015/11/26(木) 10:12:43.24ID:wjty/3s6
>>531
ここにも勘違いしてる奴がいた
TDDはよりよい設計をもたらすものじゃない

TDDは、自分が正しいと思った設計で、それをコーディングするときに、テストの力を借りて
確信を得ながらコーディングするための手法だ

「自分が正しいと思った設計」が「Good Design」じゃない奴は、どんな開発手法を使っても
自動的には「Good Design」にはならない

533デフォルトの名無しさん2015/11/27(金) 17:53:44.15ID:c/N8jVfb
ほんそれ

534デフォルトの名無しさん2015/11/27(金) 18:02:19.08ID:Ib2iKJmv
>>532
TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。

535デフォルトの名無しさん2015/11/27(金) 18:06:37.23ID:c/N8jVfb
>正しく無い設計

この「無い」の漢字の使い方は可笑しい

これフィードバックな

536デフォルトの名無しさん2015/11/27(金) 18:29:00.24ID:R6S7u3+S
>>534
コードを全て実装した後でテストが失敗したとき、それは
・間違った実装をした
・テストの期待値が間違っていた
というのがわかる位だよ。

正しくない設計(というか稚拙な実装)でも、正しい結果(期待値と合致する)であれば、
たいていは気づかない。

537デフォルトの名無しさん2015/11/28(土) 22:21:29.95ID:bl9Uvb4J
三大期待しすぎてガッカリされる手法
オブジェクト指向
リファクタリング
TDD

538デフォルトの名無しさん2015/11/29(日) 11:20:08.54ID:Qj6U8mrf
オブジェクト指向が手法?

539デフォルトの名無しさん2015/11/29(日) 12:57:18.55ID:MDC+yNGn
>>535
喜んで頂けて幸いです。

540デフォルトの名無しさん2015/11/29(日) 14:50:26.11ID:ywUk37EG
>>536
TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。
テストは漫然とやるのではなく、情報収集の手段だと考えてやることが大事だよ。

541デフォルトの名無しさん2015/11/30(月) 11:50:49.60ID:l98GVpDh
>>540
> TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。

そういうことを経てTDD用のテストとコードが完成したとき、その設計がGood Designではないと
いうことは気づかないということだよ。

テスト容易性やネーミングは、Good Designのほんの一部。

542デフォルトの名無しさん2015/11/30(月) 15:39:28.85ID:NGwAlAWY
>>541
そりゃTDDのプロセスが1周すれば、残るのはTDDでは気付けない事や割りに合わないことが残るに決まってるよね。

TDDが完全に役に立たないと言いたいのではなくて、より良い設計を目指す手法としては割りに合わないと言いたいのだと思うけど、ではTDDより良い手法としては何があると主張してるのかな?

543デフォルトの名無しさん2015/11/30(月) 16:20:33.71ID:l98GVpDh
>>542
勘違いしてるかもしれないけど、俺は超TDD派だし、日々TDDでコーディングしてる。
ただ、TDDはよりよい設計を導き出す手法ではないと言ってるだけ。

もう少し言うと、「気付けない事」の中には「思い込みバグ」なんかも含まれる。
自分がそれが正しいと思ったら、それが正しくあるようなテストとコードを書くため、
それがバグであることがわからない。
もちろん、要求仕様との乖離があってもわからない。

TDDはそういうものを検出するものではない。

544デフォルトの名無しさん2015/11/30(月) 20:00:07.27ID:JmXUnbN0
TDDは万能薬じゃないって解っていればOKなのだが、TDDのテストが通るからOKみたいなのはあり得ないってだけでしょう?
想定していない事態はTDDじゃ検出できない(想定外の事が起きたときに加える事は当然だけど)

テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。

545デフォルトの名無しさん2015/12/01(火) 11:33:20.20ID:Fb8Lo38E
>>544
俺に対して何を言いたいのか良くわからないが、俺は
>>534
> TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。
を否定しただけだよ。

546デフォルトの名無しさん2015/12/01(火) 11:36:18.07ID:Fb8Lo38E
>>544
> テストは自分の想定している事態に対してコードが正常であるって保証をプログラマに与えてくれるだけでしかないって言う部分がなぜか万能薬みたいに語られるのってエヴァンジェリストが悪いとしか思えない。
エヴァンジェリストは、「○○は万能薬ではない」って大抵言ってると思うが。

「○○は万能薬」と思う(勘違いする)のは、良くわかってない奴か、「○○は万能薬だと言われている」
ことにしてdisりたい奴だけじゃないの?

547デフォルトの名無しさん2015/12/01(火) 13:00:01.79ID:j87epvlp
>>543
どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
より良い設計というのはバグが無いという意味ではなくて、費用対効果の面で妥当な設計、と言い換えても良いけど。

新規の何らかのクラスを設計するときに、シーケンス図を書いて複数人でレビューしてから実装には入った方が費用対効果が高いのか、TDDで実装してから本体とテストコードをレビューした方が費用対効果が高いのか?
もし、TDDの方が高いとき、それは何故なのか?

っという観点の話にすれば、俺の主張は以下になる。

TDDはテストによってより早くフィードバックが得られるから費用対効果が高いが、そのフィードバックを解釈するのにも経験が必要で、テストが通りさえすれば良い、という考え方では効果は発揮できない。
また、レビューアにもフィードバックを解釈する能力が要求されるうえ、ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
シーケンス図の方も書けば良い設計になるわけじゃないし、シーケンス図から問題点を読み解く能力が必要だが、おそらくTDDよりはレビューが易しい気がする。
だが、TDDのテストは実行可能ということが利点であり、レビューアが疑問があればテストを追加して実行することが出来る。これを利用すれば、費用対効果を更に高めることが出来るのではないか?

548デフォルトの名無しさん2015/12/01(火) 14:07:41.90ID:Fb8Lo38E
>>547
本当にTDDを理解して実戦しているのか疑わしいレベル。

> そのフィードバックを解釈するのにも経験が必要
意味がわからない。

テストによるフィードバックは失敗あるいは成功しかなく、正しく実装できたはずなのに失敗するのは、
・テストが間違っている
・正しく実装できたはずというのが思い違い
のどちらか、あるいはその両方しかなく、解釈もクソもない。

自分が書いたテストが失敗して、その原因もわからないレベルなら、それはTDDをする資格がない。
というか、そんな奴にプロダクトコード書かせるな。

> ペアプログラミングでない場合はテストがNGになった時点の情報が得られないため、
> 設計者よりも少ない情報から設計を判断するための高い能力が必要になるかもしれない。
これも意味がわからない。

> どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
そもそも、TDDは設計手法というより開発手法と言うべきで、極言すれば実装手法でしかない。

というか「よい設計」の定義が俺と大幅にずれてる気がする。
俺が思う「よい設計」というのは、例えば
・SOLID原則が守られている(あるいはそれほど重大な違反は無い)
・カプセル化が守られている
・メンテナンス性が良い(リーダビリティが良い)
・パフォーマンスが良い
などなど。

そういう意味の「よい設計」ができる奴は、TDDをしなくとも良い設計はできる。

549デフォルトの名無しさん2015/12/01(火) 14:10:57.54ID:Fb8Lo38E
あと、TDDにおける「素早いフィードバック」というのは、
・正しくテストが実装できたであろう実感(red -> green)
・思い通りのコードが実装できたであろう実感(green -> refactoring -> green)
だぞ。
設計が正しい、あるいは妥当であるというフィードバックではない。

550デフォルトの名無しさん2015/12/04(金) 15:28:40.97ID:dm9hxmiU
>>547
今時、シーケンス図を書いて複数人でレビューしてから実装に入るって、どんな分野のどれくらいの規模なの?
リファクタリングが一般化した現在、クラス図でさえ事前にかっちりしたもの書くと手戻りが発生していやがられるのに。

551デフォルトの名無しさん2015/12/14(月) 22:58:51.50ID:dPco7zPj
手戻りが嫌ならプログラムを書かなければいい

552デフォルトの名無しさん2015/12/16(水) 07:23:08.19ID:JxdBAlmf
それは言える
メタプログラミングでプログラムは自動生成にしておけば
手戻り発生しても仕様書直すだけで済む

553デフォルトの名無しさん2016/02/14(日) 07:50:17.63ID:KRGWcZPF
自動生成するプログラムの修正が必要になるだろタコ。

554デフォルトの名無しさん2016/04/01(金) 19:49:18.66ID:xvbiumjA
test

555デフォルトの名無しさん2016/04/18(月) 21:10:16.12ID:WJpLEkGK
カバレッジって自動じゃないテスト(ようは手動の結合テスト)でも使えんの?

556デフォルトの名無しさん2016/04/18(月) 21:36:07.56ID:QSS7pC1U

何を言ってるのかさっぱり理解できない

557デフォルトの名無しさん2016/04/18(月) 22:20:56.27ID:i/DZEEkh
>>555
使えるってどういう意味で?

新着レスの表示
レスを投稿する