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

**デフォルトの名無しさん** · 2010/09/19(日) 21:26:12

テスト駆動開発 (test-driven development; TDD) についてﾏﾀｰﾘ語りましょう

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

**デフォルトの名無しさん** · 2014/04/24(木) 17:32:03.50

彼らは自分のエゴを満たすためにコードを書いてるんだから、
金色の牛を殺したりしたらダメだよね?(´・ω・｀)

**デフォルトの名無しさん** · 2014/04/25(金) 16:52:52.53

>>380
一行目から引いた

**デフォルトの名無しさん** · 2014/04/28(月) 12:40:27.17

Unit Test Frameworks
よんだけど、CPPUNITのことが全然書いてないので
CPPUNITの高度な使い方ってどうやってわかりますか？

**デフォルトの名無しさん** · 2014/04/28(月) 15:56:01.02

>>383
> Unit Test Frameworks
これ何

**デフォルトの名無しさん** · 2014/04/28(月) 15:59:59.35

UnitTestFrameworks.pdf?

**デフォルトの名無しさん** · 2014/04/28(月) 16:19:09.38

つか、CppUnitの高度な使い方って何よ？

**デフォルトの名無しさん** · 2014/04/28(月) 16:20:09.84

>>385
> UnitTestFrameworks.pdf?
何それ？何かの海賊版か？

**デフォルトの名無しさん** · 2014/04/28(月) 16:23:45.04

抽象クラスのテストを作って派生クラスのテストでテストしたいクラスを初期化する方法とか。

**デフォルトの名無しさん** · 2014/04/28(月) 16:24:20.94

UnitTestFrameworks.pdf
で検索すると出てくる著作権フリーの書籍。

**デフォルトの名無しさん** · 2014/04/28(月) 16:27:49.28

>>388
ちゃんとわかる文章書け。
つか、ほんとにそれ「CppUnitの高度な使い方」に関する疑問なのか？

**デフォルトの名無しさん** · 2014/04/28(月) 16:29:49.62

>>389
> UnitTestFrameworks.pdf
> で検索すると出てくる著作権フリーの書籍。
なんでずばっとURL書かないの？
俺が検索したら、O'REILLYの奴しか見つからなかったが。
これ、フリーじゃないだろ。

**デフォルトの名無しさん** · 2014/04/28(月) 16:30:35.56

>>391
Ｏ'ＲＥＩＬＬＹはフリー

**デフォルトの名無しさん** · 2014/04/28(月) 16:34:49.54

>>392
まさか、DRMフリーの意味がわからんのか？

**デフォルトの名無しさん** · 2014/04/28(月) 16:46:40.37

PDF の各ページのフッタ見ればわかるけどフリーで配布されてるわけじゃないね

**デフォルトの名無しさん** · 2014/04/28(月) 16:51:24.25

なんかの記事で見たけど、無断配布を禁止するより
しない方が本が売れるからわざとそうしてるらしい。

**デフォルトの名無しさん** · 2014/04/28(月) 16:56:55.25

>>395
> なんかの記事で見たけど、無断配布を禁止するより
> しない方が本が売れるからわざとそうしてるらしい。
どこの記事だよ？
O'reillyはDRMはフリーにしたけど、無断配布は禁止だろ。

**デフォルトの名無しさん** · 2014/04/28(月) 20:05:02.12

なんだ釣りか

**デフォルトの名無しさん** · 2014/04/29(火) 10:12:01.42

別にDRMフリーって無料配布を禁止してないわけじゃないんだけどなw

**デフォルトの名無しさん** · 2014/04/29(火) 10:15:16.74

A. オライリー・ジャパンが販売する書籍（Ebookも書籍だと考えています）は、
コピー・フリーではありますがコピーライト・フリーではありません。
日本国の著作権法による保護を受けており、
著作権法で定められた範囲を超えた複製、頒布、
送信などは、
著作権法に抵触する恐れがありますのでご注意ください。

**デフォルトの名無しさん** · 2014/04/30(水) 12:43:00.88

著作権フリーだの無断配布だの意味不明な俺用語でかたるのがおかしい

**デフォルトの名無しさん** · 2014/05/08(木) 10:55:00.04

> なんか誤解してるっぽく見えるからそれをときたいだけなのに原理主義だの教条主義だの
> テスト厨だのって言われるのは心外っすね。。こちらだって別に銀の弾丸だと思ってないし、
> ただ誤った理解を訂正したいだけなのに。。

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

**デフォルトの名無しさん** · 2014/05/08(木) 13:18:58.75

そうだな
TDDという概念自体が完全に誤ったもの
動いてるコードに手を触れないことこそが真理

**デフォルトの名無しさん** · 2014/05/08(木) 23:11:10.80

>>402
君、概念以前にTDDが何なのかすらよく分かってないでしょ

**デフォルトの名無しさん** · 2014/06/14(土) 11:06:05.15

うんこ

**デフォルトの名無しさん** · 2014/07/21(月) 15:26:18.47

オウンコ

**デフォルトの名無しさん** · 2014/07/21(月) 15:27:39.55

マンコ

**デフォルトの名無しさん** · 2014/08/06(水) 12:12:57.58

テスト鳥文

**デフォルトの名無しさん** · 2014/08/19(火) 01:55:15.38

とりぶん？

**デフォルトの名無しさん** · 2014/09/29(月) 15:59:03.19

なぜ流行らなかったスレが死滅したな

**デフォルトの名無しさん** · 2014/09/29(月) 22:02:10.49

あのスレのカオスっぷりを見れば
なぜ流行らなかったのか良く分かる

**デフォルトの名無しさん** · 2014/09/29(月) 22:59:57.93

2ちゃんねらーの脳みそではテストなんて書けるわけがなかったってことだ

**デフォルトの名無しさん** · 2014/09/30(火) 08:06:51.52

TDDはともかくユニットテストまで否定かよ
恐れ入る

**デフォルトの名無しさん** · 2014/10/01(水) 16:56:59.90

TDDやユニットテストを否定する奴って、経験ゼロなのに経験豊富な奴の知見や実感なんかを否定するよね。
あと、自分の嫌いなスクリプト言語をわざわざdisりに行く奴とメンタルが似てる気がする。

**デフォルトの名無しさん** · 2014/10/01(水) 17:01:54.48

自己紹介ですね
わかります

**デフォルトの名無しさん** · 2014/10/01(水) 22:34:56.80

>>413
>>380

**デフォルトの名無しさん** · 2014/10/02(木) 14:30:41.58

>>415
http://blog.fieldnotes.jp/entry/2014/05/07/225129

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

**デフォルトの名無しさん** · 2014/10/02(木) 14:37:04.66

あとこれも追加。

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

**デフォルトの名無しさん** · 2014/10/02(木) 21:31:51.50

>>416
そのリンクを出して何を言いたいのか分からない
もう一回>>413と>>380を嫁

**デフォルトの名無しさん** · 2014/10/03(金) 11:17:58.55

>>418
えっとね、>>380も>>413も書いたの俺なんだわ。
逆にお前が何を言いたいのかわからんわ。

**デフォルトの名無しさん** · 2014/10/03(金) 23:03:06.98

>>419

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

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

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

**デフォルトの名無しさん** · 2014/10/06(月) 10:30:55.78

>>420
アスペなの？
俺が言ったのは傾向だよ。

**デフォルトの名無しさん** · 2014/10/06(月) 22:45:50.57

TDDは慣習

**デフォルトの名無しさん** · 2014/10/12(日) 02:49:57.49

組み込みなんだが

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

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

**デフォルトの名無しさん** · 2014/10/12(日) 10:48:18.63

気になるのはコンパイラが別になるってことだけ？
それなら解析環境（？）でテストがパスすればテストしたと言えるだろう

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

**デフォルトの名無しさん** · 2014/10/12(日) 11:10:47.48

最適化のバグでひどい目に遭ってからそのへんの互換性は信用出来ないと思い知ったわけだが
それでもテストしないよりはマシ

**デフォルトの名無しさん** · 2014/10/12(日) 15:18:45.36

>>424
他にも色々ある

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

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

ｘ＋１の関数に１をいれて２になりましたとか
そんな説明は求めてないのだが

**デフォルトの名無しさん** · 2014/10/12(日) 21:43:25.28

>>426
TDDがどんなものか、何の略かまでは分かる？
クソなソースになっているのならどうしようもないだろう

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

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

**デフォルトの名無しさん** · 2014/10/12(日) 22:13:02.74

>>426
TDDで目指すのは小さなフィードバックループを作ること
開発者が安心を得つつコーディングできること
安心というのは、ここでいうと例えば「実機で確認されていないコード・機能をベースに、それに依存したコードをさらに積み上げていくこと＝不安な状態」的な

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

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

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

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

**デフォルトの名無しさん** · 2014/10/13(月) 10:22:06.70

>>428
ありがとう

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

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

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

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

**デフォルトの名無しさん** · 2014/10/14(火) 11:44:30.46

>>428
> 実機での確認をいかに頻繁に行ってフィードバックを得られるか、が重要になる
> そうすると一般的なTDDは実践しづらくなると思う。
組み込みの種類にもよるだろうけど、対象物をmock（あるいは、シミュレータ）で作って
実機なしに開発・テストできるようにするのが、自動テストをやる派の中では一般的だと思う。

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

**デフォルトの名無しさん** · 2014/10/15(水) 22:41:20.51

UARTなりＣＡＮなりイーサネットなり
この部分は完璧に通信できるものとして実装するでおｋ？

**デフォルトの名無しさん** · 2014/10/16(木) 10:27:00.84

エラーのシミュレーションはするべき

**デフォルトの名無しさん** · 2014/10/16(木) 13:38:30.32

異常系の仕様が定義されていればそれに対応する
それ以外は単体テストの範囲ですらない

**デフォルトの名無しさん** · 2014/10/16(木) 13:56:42.86

>>433
定義あるいは明示されていない異常が発生して鼻から悪魔が出ても、それは俺のせいじゃないから
問題ないという主義ですか？

**デフォルトの名無しさん** · 2014/10/16(木) 17:14:14.25

まるで公務員の主張だな

**デフォルトの名無しさん** · 2014/10/16(木) 19:29:56.64

一緒に仕事したくねーな

**デフォルトの名無しさん** · 2014/10/16(木) 21:49:07.00

縦割りはそういうもの

**デフォルトの名無しさん** · 2014/10/17(金) 01:41:12.71

担当者が設計と開発で分かれているなら>>433が正しい

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

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

**デフォルトの名無しさん** · 2014/10/17(金) 10:40:07.93

>>438
設計する人は、たとえばファイルに保存するときに起こり得るエラー原因ごとにどう対処すべきかを
網羅したりするんですか？

**デフォルトの名無しさん** · 2014/10/17(金) 11:21:29.10

printf() の戻り値見ろと言っているに等しい

**デフォルトの名無しさん** · 2014/10/17(金) 15:20:26.07

>>439
必要なら処理中の突然の電源断やディスクやメモリの破損なんかも網羅するよ
必要か（現実味があるか）どうかを切り分けるのが仕事だよ

**デフォルトの名無しさん** · 2014/10/17(金) 16:05:39.88

>>441
ちょっと議論するのめんどくさいんだけど、開発者の裁量内で判断する異常処理ってないのという疑問なんだけど。
そういう判断を一切する必要がない開発者は、エンジニアやプログラマとは呼ばずに、コーダーやパンチャーって呼ばれると思うんだけど。

**デフォルトの名無しさん** · 2014/10/17(金) 22:32:13.59

>>442
たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
インプリメンテーション（どう起こすか）は明確に分けるべき。
ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。

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

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

**デフォルトの名無しさん** · 2014/10/17(金) 22:37:06.62

TDD (BDD) には、インプリメンテーションをやるまえに
テストケースを作ってアーキテクチャを確認しようぜ
という意味も有る。

**デフォルトの名無しさん** · 2014/10/18(土) 00:53:05.90

そりゃプログラマだってアホじゃないんだから要件漏れ気づくこともあるよ
テストを作成していて漏れに気づくことだって多いしね

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

**デフォルトの名無しさん** · 2014/10/18(土) 12:25:58.33

なるほど

**デフォルトの名無しさん** · 2014/10/18(土) 15:13:02.82

>>445
あんた公務員か

**デフォルトの名無しさん** · 2014/10/18(土) 15:19:28.52

たぶんプログラマって言葉の定義が違うんじゃね
SE/PG世界のプログラマは普通のプログラマと別の概念

**デフォルトの名無しさん** · 2014/10/18(土) 15:52:52.83

>>439
Javaの例外は3種類あって、
プログラマが主に想定する例外は、Exception

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

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

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

**デフォルトの名無しさん** · 2014/10/18(土) 16:24:30.31

アーキテクチャをそんな意味で使うの初めて見た

**デフォルトの名無しさん** · 2014/10/19(日) 00:06:51.41

>>440
> printf() の戻り値見ろと言っているに等しい

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

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

**デフォルトの名無しさん** · 2014/10/20(月) 11:17:44.91

>>443
> たとえ一人でやっている場合でも、アーキテクチャ（何が起きるか）と、
> インプリメンテーション（どう起こすか）は明確に分けるべき。
> ましてや複数人でやるんなら、アーキテクチャが明示されることが必要。
ちょっと俺とは「アーキテクチャ」の使い方が違うようだ。

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

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

**デフォルトの名無しさん** · 2014/10/21(火) 17:54:15.96

コードを書かない？設計者が、最終的に使用するミドルウェア・ライブラリ・APIに精通してる奴多すぎ。
んで、if (エラー条件)となる部分を全部設計書に明記するだって？
どんだけ分厚い設計書なんだよ。

**デフォルトの名無しさん** · 2014/10/21(火) 17:56:11.27

>>451
> 例外がある言語ならすべての行でエラーが起きる可能性がある
例外がありゃあったで、別に考えないといけないことも増えるんだけどね。

**デフォルトの名無しさん** · 2014/10/22(水) 01:30:09.07

>>453
冗談と思うかもしれないが、開発を海外に投げるときは
それくらいしないと酷いことになる

**デフォルトの名無しさん** · 2014/10/22(水) 10:11:18.50

>>455
オフショアの話なんて誰もしてないと思うが

**デフォルトの名無しさん** · 2014/10/22(水) 12:52:41.64

>>455-456
わかるわ
日本人同士で日本語で会話しててもこうだもんな

**デフォルトの名無しさん** · 2014/10/22(水) 13:54:32.30

>>457
何を言いたいのかさっぱりわからん
確かに日本人同士でも話が通じることはまれかもな

**デフォルトの名無しさん** · 2014/10/22(水) 18:54:17.18

>>444

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

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

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

**デフォルトの名無しさん** · 2014/10/22(水) 19:01:41.56

テストの使い方を間違ってる

**デフォルトの名無しさん** · 2014/10/22(水) 19:16:11.80

レガシーコード改善ガイド

**デフォルトの名無しさん** · 2014/10/23(木) 13:10:10.45

>>459
> そのほかのｃファイルのヘッダを全部インクルードしてて
まずここから改善していけば？

**デフォルトの名無しさん** · 2014/10/23(木) 13:42:02.91

よくよく見てみたら相互参照や循環が２～３箇所で
それを除いて解きほぐしたら案外単純…ってことが多いんじゃないかな

**デフォルトの名無しさん** · 2014/10/24(金) 01:19:22.31

実装済みならE2Eテスト書けば

**デフォルトの名無しさん** · 2014/10/25(土) 23:02:32.16

スパゲティ

**デフォルトの名無しさん** · 2014/11/08(土) 12:34:57.35

パスタ

**デフォルトの名無しさん** · 2014/11/09(日) 12:21:49.68

テスト駆動ってC0カバレッジの確認しづらくない

**デフォルトの名無しさん** · 2014/11/09(日) 20:05:25.41

最後に確認して足りなきゃ足したら良いんじゃないの？

**デフォルトの名無しさん** · 2014/11/09(日) 20:47:28.67

お前はなんにもわかってない

**デフォルトの名無しさん** · 2014/11/09(日) 20:56:21.42

まさかC0を通すためにテストを書き直すとかやってるんじゃないだろうな・・・

**デフォルトの名無しさん** · 2014/11/16(日) 09:33:56.00

>>470

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

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

**デフォルトの名無しさん** · 2014/11/16(日) 10:04:32.62

>>471
なんで俺にレス付けたのか知らんがそんなの知っとるがな

**459** · 2014/11/22(土) 19:34:49.92

>>462
職場の製品プログラムなんで
末端の俺ごときがインクルードをいじると鬼のように罵倒される

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

**デフォルトの名無しさん** · 2014/11/22(土) 19:48:51.79

罵倒されるような人間にルール作りを任せる？　ありえんわ
出来ても誰も守らねーだろう
適当に作っとけよ

**デフォルトの名無しさん** · 2014/11/22(土) 19:56:54.71

一応フォローしておくと>>473が悪いわけじゃない
依頼した上司が無能ってことだ

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

**デフォルトの名無しさん** · 2014/11/23(日) 14:05:47.05

473-475は無能

**デフォルトの名無しさん** · 2014/11/23(日) 14:26:41.19

476がスゲー解決策を提示してくれるようです

**デフォルトの名無しさん** · 2014/11/25(火) 11:06:37.29

>>459
> そのほかのｃファイルのヘッダを全部インクルードしてて
というのが、「その他の.cファイルがインクルードしてるファイルを、全部インクルードしている」という
意味なら、不要なインクルードファイルを削るのは何も問題がない（問題があればビルドできない）し、
メンテナンスコストが下がるという大きなメリットがある。

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

**デフォルトの名無しさん** · 2014/11/25(火) 23:45:47.25

使ってないincludeをコメントアウトしただけで動かなくなることもあるからなぁ
末端のPGが勝手にいじるのもどうかと思うよ

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

**デフォルトの名無しさん** · 2014/11/26(水) 19:32:04.26

組み込み系のひとが書くCなんてめちゃくちゃだよ