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

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

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

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

**デフォルトの名無しさん** · 2014/02/13(木) 00:48:59.46

>>337
> プログラミングにおいていちばん重要な財産はテストであり，
これは嘘ｗ
あたりまえだけどテストよりも動くコードの方が重要。

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

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

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

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

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

**デフォルトの名無しさん** · 2014/02/13(木) 01:16:10.11

>>338
アプリコードの方が重要って考えは視点が違うだけだからなんとも

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

**デフォルトの名無しさん** · 2014/02/13(木) 02:24:17.12

>>339
反応する意味がわからない？
ただ書いただけだろ？
何か問題が？

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

**デフォルトの名無しさん** · 2014/02/13(木) 09:57:16.39

プロレスで相手の手の内を出させないままキックだけで勝って俺TUEEEみたいな

**デフォルトの名無しさん** · 2014/02/13(木) 11:04:59.49

おまえら勘違いすんな
> テストが無事なら元と同じ品質のコードをもう一度書くことができる。
同じ*品質*のコードといってるんだ
テストが保証するのはコードの品質であってアプリの価値ではない
ましてや同じ入力画面を復活させる事では全くない

**デフォルトの名無しさん** · 2014/02/13(木) 11:22:44.29

ゴミページを擁護してる奴は何が目的なんだ

**デフォルトの名無しさん** · 2014/02/13(木) 13:59:44.58

TDDどうこうよりも、テスト対象のクラスを継承したテストクラスを作って、テスト結果の確認をテスト対象クラスのメンバに設定された値でアサートするというやり方がセンスないわ。

**デフォルトの名無しさん** · 2014/02/13(木) 20:48:44.35

アプリのソースだけ残った場合と
テストコードだけが残った場合

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

**デフォルトの名無しさん** · 2014/02/13(木) 20:55:48.07

>>345
リファクタリングしまくる人の場合は、残ったソースをいずれ破棄したり書き直したりしてしまうので、
テストコードだけ残った方が安価なときもある。

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

**デフォルトの名無しさん** · 2014/02/13(木) 22:49:05.90

TDDはアプリのソースとかテストコードがどっちが残ると～とかそういうことを
語るもんではないんだが

**デフォルトの名無しさん** · 2014/02/14(金) 01:07:04.09

おおよそ、テストをどうやって書くかを考えるのが設計になり、
テストをどのように満たすかを考えるのが実装になる。

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

品質との関連性は微妙

**デフォルトの名無しさん** · 2014/02/14(金) 02:07:53.24

＞テストとコードを共に成長させていって開発を進めるのだから、
成長が順調に進むのであればテストファーストもコードファーストも大差なく
テストとコードのどちらを先に書くかの順番の違いしかないが、

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

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

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

＞品質との関連性は微妙
実装フェーズが完了した段階ではコードもテストも固まっているから
テストファーストでもコードファーストでも同等の成果物が作成されて
同等の品質が得られているはず、ということなんだろうか、

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

**デフォルトの名無しさん** · 2014/02/14(金) 10:08:16.40

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

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

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 10:51:38.30

>>351
> > テストが無事なら元と同じ品質のコードをもう一度書くことができる。－この考えを立証すべく
>
> って考え方を言ってるんだよ
> お前は抽象的な話しが出来ない奴か？

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 11:11:56.77

後付けのC1カバレッジ100%で全ての副作用に対するassertionが記述されている
テスト一式があれば、元コードと同等のものを翔かもしれないが、このこととTDDは
一切関係無いね。

**デフォルトの名無しさん** · 2014/02/14(金) 11:31:08.45

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 11:56:51.72

>>354
> 論破って…単なる仮説を立てただけだろ。立証してから言ってくれ

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

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 12:45:53.91

>>351
なんであの糞記事を擁護するの？

**デフォルトの名無しさん** · 2014/02/14(金) 12:52:21.25

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

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

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

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 14:24:13.22

>>357
言葉遊びして楽しい？
それより、なんであの糞記事を擁護するのか教えてよ。

**デフォルトの名無しさん** · 2014/02/14(金) 14:31:22.73

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

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

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 17:22:33.79

>>357
そもそも
＞テストが無事なら元と同じ品質のコードをもう一度書くことができる。
なんてことが必要になる状況はめったにない、で論破じゃないかと。

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

**デフォルトの名無しさん** · 2014/02/14(金) 17:32:25.39

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

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

**デフォルトの名無しさん** · 2014/02/14(金) 22:19:43.22

>>353
そうだな。誰もそこまでのテストは求めていないし、そんなことする気にもなれない。

**デフォルトの名無しさん** · 2014/02/15(土) 00:21:14.85

テストとソースって
たまごとにわとりの関係なの？

**デフォルトの名無しさん** · 2014/02/15(土) 07:15:22.29

たまごが成長すれば、ニワトリになり
そのニワトリが複数個のたまごを生む。
そのたまごがそれぞれ成長し
それぞれがたまごを複数個生む。

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

**デフォルトの名無しさん** · 2014/02/15(土) 09:04:51.54

カバレッジは、ISOとかで必要なところもあるんだろう
あれも結局は認証されたxUnitでテストするらしいが

**デフォルトの名無しさん** · 2014/03/02(日) 15:11:51.03

カバレッジのスレないのでここで。

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

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

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

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

**デフォルトの名無しさん** · 2014/03/02(日) 15:58:52.16

それは、なしです

**デフォルトの名無しさん** · 2014/03/02(日) 16:30:47.67

実は関数読んでなかったり別の関数呼んでたらどうするわけ？

**デフォルトの名無しさん** · 2014/03/02(日) 17:01:14.12

>367
理由は何ですか？

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

**デフォルトの名無しさん** · 2014/03/02(日) 17:46:28.42

>>366はガバレッジとテストの関係について何か壮大に勘違いしてると思う

**デフォルトの名無しさん** · 2014/03/02(日) 18:15:04.54

なにがしかでも作業効率が改善できてるならいいんじゃないの

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

**デフォルトの名無しさん** · 2014/03/02(日) 19:06:23.64

>>370 >>371
話ちゃんと聞いてね。

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

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

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

**デフォルトの名無しさん** · 2014/03/02(日) 19:12:20.55

話を聞いてないように見えるのはお前が基本を理解してないか
もしくは説明が下手だからだ

**デフォルトの名無しさん** · 2014/03/02(日) 19:31:34.78

あぁ、わかった。

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

**デフォルトの名無しさん** · 2014/03/03(月) 17:40:56.93

>>366
テストは、実際どのように使うのかというドキュメント性があり、また、テストを書くことによって設計が洗練されるということもあるので、ただ実行するだけのメソッドも意味は無くないと思うよ。

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

書いたら保守せなあかん
簡単に書けるからと書くと、負の遺産になりかねないかも

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

2014/03/28(金) 03:11:16.97

てｓ

**デフォルトの名無しさん** · 2014/04/06(日) 10:39:53.51

２つ質問です。
テストを作ってから同じテストを別のオブジェクトにするとき
別のテストをつくりますか？
リファクタリングをするときソースを書き換えてもとに戻せなくならないように
リファクタリングをする前のファイルを保存しておきますか？

**デフォルトの名無しさん** · 2014/04/06(日) 10:44:48.65

>>378
たいていのテスト環境にテストコードの再利用の仕組みはあると思うけど。

バージョン管理しろよ。

**デフォルトの名無しさん** · 2014/04/24(木) 16:15:35.14

DHH(Ruby on Railsの作者)の"TDD is dead. Long live testing." （の訳）
http://d.hatena.ne.jp/yach/20140424#p1

**デフォルトの名無しさん** · 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

縦割りはそういうもの