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

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

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

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

**デフォルトの名無しさん** · 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なんてめちゃくちゃだよ

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

>>480
それ単にその人がレベルが低かっただけじゃないか。
組み込み系の組織では、MISRA-Cを意識してるとこ多数だよ。

**デフォルトの名無しさん** · 2014/12/22(月) 15:36:54.08

組み込み系が酷くなかったいう話は聞いたことがない
自分たちはちゃんとやってるつもりだったのか

**デフォルトの名無しさん** · 2014/12/22(月) 17:25:12.55

組み込み系が酷いということなら、業務系も酷いぞ
ゴミの寄せ集めだし

**デフォルトの名無しさん** · 2014/12/24(水) 00:40:32.72

酷い方向が違うんだよな。
どっちも酷いのは多い

**デフォルトの名無しさん** · 2014/12/25(木) 01:35:17.73

組み込みや業務系が酷いと言われるのはライフサイクルが長いからだよ

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

**デフォルトの名無しさん** · 2014/12/31(水) 16:18:59.05

組み込みが酷いのはハードやコンパイラの制約によるもの
業務系が酷いのは要員のレベルのばらつきの大きさによるもの

**デフォルトの名無しさん** · 2014/12/31(水) 16:49:50.16

組み込みも要員のレベルとさせてくれ
環境があるのに頑なに適応せずに昔のままをやりたがる

**デフォルトの名無しさん** · 2014/12/31(水) 16:55:18.42

>>487
ハード完成してなくてI/F仕様書もレビュー通ってないけどこれで実装お願い！
開発環境？　ベストなものをお願いします！
って言われたことある？

**デフォルトの名無しさん** · 2014/12/31(水) 17:19:00.28

>>488
ある、キーボードぶん投げた希有な事例だった。
割とマジで開発馬鹿にすんなゴルァって部長ですらぶち切れてた

**デフォルトの名無しさん** · 2014/12/31(水) 17:36:35.58

ソフト屋さんが仕様決めて！その通り作るからってのはあったな
おまえ回路図で線繋ぐだけかよって…
ハードのデバッグもソフト屋まかせな奴だったのでキレました

**デフォルトの名無しさん** · 2015/01/03(土) 22:02:59.55

亀レスだけど

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

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

**デフォルトの名無しさん** · 2015/01/04(日) 00:56:12.46

下手な使い方して落とし穴掘られるリスクより
ハングさせてハードリセットする方がマシというケースも多い

**デフォルトの名無しさん** · 2015/01/12(月) 00:20:00.80

でテスト駆動ってどうなのよ

**デフォルトの名無しさん** · 2015/01/12(月) 00:22:31.65

終わった

**デフォルトの名無しさん** · 2015/01/12(月) 08:58:02.07

テストなんて書くだけ無駄
コードとテストで仕事が2倍になるだけ
どうせ一回通ったら用済みなんだから書く必要ない

**デフォルトの名無しさん** · 2015/01/14(水) 20:01:04.12

TDD by example 再出発

**デフォルトの名無しさん** · 2015/01/14(水) 21:26:18.53

>>495
じゃあテスト仕様を先に作るだけなら問題ないの？

**デフォルトの名無しさん** · 2015/01/18(日) 07:54:29.17

yes

**デフォルトの名無しさん** · 2015/01/18(日) 09:12:40.34

一回通ったら用済みとか言ってる時点でまともな開発やったことない奴だってわかる

**デフォルトの名無しさん** · 2015/01/18(日) 10:11:14.89

そんな香具師と判ってて相手するとか
どんだけ親切なんだ

**デフォルトの名無しさん** · 2015/02/21(土) 16:03:21.19

むしろテストが一度でも行われていたらラッキー

**デフォルトの名無しさん** · 2015/02/22(日) 14:32:31.50

どっかのSEを自称するひとがW字開発とか意気込んでたけど
これもテスト駆動ってやつ？

**デフォルトの名無しさん** · 2015/02/22(日) 16:00:00.52

違うんじゃね

**デフォルトの名無しさん** · 2015/02/23(月) 21:53:44.54

w字開発は悲劇の開発

**デフォルトの名無しさん** · 2015/02/23(月) 22:53:58.10

W字って初めて聞いた
仕様変更や手戻りが発生したら大変そうなんだけどどうなの

**デフォルトの名無しさん** · 2015/03/05(木) 20:35:18.19

仕様変更の度に試験仕様書の修正が発生します

**デフォルトの名無しさん** · 2015/03/05(木) 21:41:49.24

仕様変更という言葉の意味を知った上で言ってるのか

**デフォルトの名無しさん** · 2015/03/06(金) 01:16:33.41

メタテストですね

**デフォルトの名無しさん** · 2015/03/07(土) 20:16:06.24

>>507
何か変か？
仕様決める→テスト仕様書作成→プログラム設計→コーティング
なんだから仕様が変わる度にテスト項目見直しだろ

**デフォルトの名無しさん** · 2015/03/07(土) 20:48:33.06

>>509
変だろ
なんでそんな当たり前のことを述べる必要があるんだ
それとも>>506には何か深い意味があるのか？

**デフォルトの名無しさん** · 2015/03/16(月) 21:05:40.30

テストプログラムのテストというのはおかしいでしょうか。

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

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

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

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

**デフォルトの名無しさん** · 2015/03/16(月) 23:22:18.02

>>511
テスト駆動の考え方がわかってないだけ

**デフォルトの名無しさん** · 2015/03/17(火) 17:20:27.93

テストプログラムのテストのテストというのはおかしいでしょうか。
テストプログラムのテストのテストのテストというのはおかしいでしょうか。
テストプログラムのテストのテストのテストのテストというのは可笑しいでしょうか。

**デフォルトの名無しさん** · 2015/03/17(火) 18:34:03.30

>>511
> テストプログラムのテストというのはおかしいでしょうか。
別におかしくないが、そのこととTDDとは何の関係もない。

**511** · 2015/03/17(火) 19:28:49.00

>>512
>>514
わかりました。
ありがとうございます。

**デフォルトの名無しさん** · 2015/03/17(火) 23:32:04.19

意外と>>513が正しいのでは

**デフォルトの名無しさん** · 2015/03/17(火) 23:38:56.12

>>516
数学的に考えれば品物が上がらない事は明白だろう？

**デフォルトの名無しさん** · 2015/03/20(金) 15:48:44.47

どこまでテストするかの話になると外部ライブラリだけでなくコンパイラやOSまで疑う必要がある
一昔前のコンパイラは多すぎてコンパイラのテストもやっていたな