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

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

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

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

**デフォルトの名無しさん** · 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まで疑う必要がある
一昔前のコンパイラは多すぎてコンパイラのテストもやっていたな

**518** · 2015/03/20(金) 15:51:36.12

訂正
>一昔前のコンパイラは多すぎてコンパイラのテストもやっていたな
一昔前のコンパイラはバグが多すぎてコンパイラのテストもやっていた

**デフォルトの名無しさん** · 2015/03/31(火) 18:51:00.25

Kindleでこんな本が発売されたのを発見。
読んでないので内容は全くわからないが、目次を見る限り、よさげな気もする。

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

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

**デフォルトの名無しさん** · 2015/03/31(火) 21:27:32.21

ステマ乙。目次どこにあるんだよ。

**デフォルトの名無しさん** · 2015/03/31(火) 21:42:50.98

あとUnityどこに関係するんだ？amazonの紹介文修正しとけよ。

**デフォルトの名無しさん** · 2015/04/01(水) 10:34:19.69

>>521
TDDの本なんてめったに出ないから紹介しただけだし。
目次は
http://book.impress.co.jp/books/1114170210
にある。
俺はTDD初心者じゃないから買わないけど。

**523** · 2015/04/02(木) 10:30:42.33

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

**523** · 2015/04/03(金) 13:21:39.26

読み終わったけど、全然駄目だった。
やはり、自分が読まないとお薦めしてはいけないね。

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

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

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

**デフォルトの名無しさん** · 2015/05/29(金) 14:19:57.76

TDDを行った時にぶつかった7つの壁
http://qiita.com/syou007/items/7d6fdf1b7b6245a07bce

**デフォルトの名無しさん** · 2015/05/29(金) 15:10:31.84

TDDに関する議論をググってみて見つけたページ。

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

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

**デフォルトの名無しさん** · 2015/06/01(月) 10:17:17.81

>>526
TDDと、品質保証のための自動テストによる単体テストを、完全に混同してる。

**デフォルトの名無しさん** · 2015/09/23(水) 22:50:15.66

qiitaにマジレス

**デフォルトの名無しさん** · 2015/09/29(火) 22:12:17.46

テスト駆動開発はゴミクズ

**デフォルトの名無しさん** · 2015/11/26(木) 08:24:06.20

Test-Driven Development is Stupid
http://geometrian.com/programming/tutorials/testing/test-first.php

**デフォルトの名無しさん** · 2015/11/26(木) 10:12:43.24

>>531
ここにも勘違いしてる奴がいた
TDDはよりよい設計をもたらすものじゃない

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

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

**デフォルトの名無しさん** · 2015/11/27(金) 17:53:44.15

ほんそれ

**デフォルトの名無しさん** · 2015/11/27(金) 18:02:19.08

>>532
TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。

**デフォルトの名無しさん** · 2015/11/27(金) 18:06:37.23

>正しく無い設計

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

これフィードバックな

**デフォルトの名無しさん** · 2015/11/27(金) 18:29:00.24

>>534
コードを全て実装した後でテストが失敗したとき、それは
・間違った実装をした
・テストの期待値が間違っていた
というのがわかる位だよ。

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

**デフォルトの名無しさん** · 2015/11/28(土) 22:21:29.95

三大期待しすぎてガッカリされる手法
オブジェクト指向
リファクタリング
TDD

**デフォルトの名無しさん** · 2015/11/29(日) 11:20:08.54

オブジェクト指向が手法？

**デフォルトの名無しさん** · 2015/11/29(日) 12:57:18.55

>>535
喜んで頂けて幸いです。

**デフォルトの名無しさん** · 2015/11/29(日) 14:50:26.11

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

**デフォルトの名無しさん** · 2015/11/30(月) 11:50:49.60

>>540
> TDDなんだから、コードを全て実装する前のテストの実装の段階でも、テストのしやすさやテスト観点、インターフェース名称などで何か気付くことがあるし、テストの失敗の仕方でもフィードバックを得られる。

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

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

**デフォルトの名無しさん** · 2015/11/30(月) 15:39:28.85

>>541
そりゃTDDのプロセスが1周すれば、残るのはTDDでは気付けない事や割りに合わないことが残るに決まってるよね。

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

**デフォルトの名無しさん** · 2015/11/30(月) 16:20:33.71

>>542
勘違いしてるかもしれないけど、俺は超TDD派だし、日々TDDでコーディングしてる。
ただ、TDDはよりよい設計を導き出す手法ではないと言ってるだけ。

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

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

**デフォルトの名無しさん** · 2015/11/30(月) 20:00:07.27

TDDは万能薬じゃないって解っていればOKなのだが、TDDのテストが通るからOKみたいなのはあり得ないってだけでしょう？
想定していない事態はTDDじゃ検出できない（想定外の事が起きたときに加える事は当然だけど)

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

**デフォルトの名無しさん** · 2015/12/01(火) 11:33:20.20

>>544
俺に対して何を言いたいのか良くわからないが、俺は
>>534
> TDDは、自分が正しく無い設計を選んでしまったときに、少しでも早くその事を知り、フィードバックするための手法だよ。
を否定しただけだよ。

**デフォルトの名無しさん** · 2015/12/01(火) 11:36:18.07

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

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

**デフォルトの名無しさん** · 2015/12/01(火) 13:00:01.79

>>543
どんな設計手法も、その手法を使わないよりも良い設計を目指すためにあると思うよ。
より良い設計というのはバグが無いという意味ではなくて、費用対効果の面で妥当な設計、と言い換えても良いけど。

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

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

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

**デフォルトの名無しさん** · 2015/12/01(火) 14:07:41.90

>>547
本当にTDDを理解して実戦しているのか疑わしいレベル。

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2015/12/01(火) 14:10:57.54

あと、TDDにおける「素早いフィードバック」というのは、
・正しくテストが実装できたであろう実感(red -> green)
・思い通りのコードが実装できたであろう実感（green -> refactoring -> green)
だぞ。
設計が正しい、あるいは妥当であるというフィードバックではない。

**デフォルトの名無しさん** · 2015/12/04(金) 15:28:40.97

>>547
今時、シーケンス図を書いて複数人でレビューしてから実装に入るって、どんな分野のどれくらいの規模なの？
リファクタリングが一般化した現在、クラス図でさえ事前にかっちりしたもの書くと手戻りが発生していやがられるのに。

**デフォルトの名無しさん** · 2015/12/14(月) 22:58:51.50

手戻りが嫌ならプログラムを書かなければいい

**デフォルトの名無しさん** · 2015/12/16(水) 07:23:08.19

それは言える
メタプログラミングでプログラムは自動生成にしておけば
手戻り発生しても仕様書直すだけで済む

**デフォルトの名無しさん** · 2016/02/14(日) 07:50:17.63

自動生成するプログラムの修正が必要になるだろタコ。

**デフォルトの名無しさん** · 2016/04/01(金) 19:49:18.66

test

**デフォルトの名無しさん** · 2016/04/18(月) 21:10:16.12

カバレッジって自動じゃないテスト(ようは手動の結合テスト)でも使えんの？

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

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