TDD と単体テストは違うってのはなんとなくわかるんだけど、単体テストは実装者が TDD でかいたテストコードとは別に単体テスト用のコードを書くの？ それとも実装者と別の人がやるの？ それとも TDD の時は単体テストなんてやんないの？
— とみたまさひろ (@tmtms) 2010, 2月 23クラスの振る舞いとか、メソッドの引数による振る舞いとかという粒度のテストって、結局実装者しかできないような気がするんだけど、そうしたら TDD と一緒にやっちゃえばいいんじゃね？ と思ったりする。
— とみたまさひろ (@tmtms) 2010, 2月 23TDDで何かが測れなくなって困るって話を聞くと、それって元々測っても意味なかったものなんじゃないの？ と思ったりする。テスト密度とかバグ密度とか。
— とみたまさひろ (@tmtms) 2010, 2月 24あれ？いつの間にか X201 発表されてた。
— とみたまさひろ (@tmtms) 2010, 2月 24Thinkpad X201 ってビジネス向けだったのか。へぇ～ http://itpro.nikkeibp.co.jp/article/NEWS/20100224/344969/
— とみたまさひろ (@tmtms) 2010, 2月 24「TDD で作成されたプログラムおよびプログラム群の品質情報を提供する」のは開発者の仕事なのかな。「品質情報」の定義にもよるけど、何が欲しいかわかってない人に対して、その人を満足させられるものは提供できない気がする。
— とみたまさひろ (@tmtms) 2010, 2月 24あー、これ行きたいな。メールすればよいのか。 "テスト本の読書会を行います。 " http://labs.unoh.net/2010/02/post_140.html
— sugamasao (@sugamasao) 2010, 2月 24MDDは品質があがる。ちなみにMはマスコットね。バグがあったらマスコットがいじめられてかわいそうだから、開発者も本気出す。
— とみたまさひろ (@tmtms) 2010, 2月 24TDDやってバグが多いチームは、やり方間違ってるか、TDDやんなくたってバグが多い。バグが多いチームには仕事をまかせないってのがいいと思うよ！
— とみたまさひろ (@tmtms) 2010, 2月 24「TDDについて」 http://togetter.com/li/6923 に「MDDで品質あがる」を追加しようと思ったけど自重した。
— とみたまさひろ (@tmtms) 2010, 2月 24こんなのあるみたいです http://pc.watch.impress.co.jp/docs/column/hot/20100210_347961.html RT @ar1: そろそろUSB3.0ついたノートって出てる?
— とみたまさひろ (@tmtms) 2010, 2月 24自分が知ってる品質管理は、プロセスから出てきた動くソフトウェアの出来ばえとプロセスの具合をみて、もっかいプロセスを微調整していくこと。それを何度も何度も繰り返すこと。決まった手順が守られているかとか、バグ数が妥当かなんてことはどうでもよい。
— 坂田晶紀 (@sakata_akinori) 2010, 2月 24このTDDの流れなら言える。 http://blog.madoro.org/mn/47 この本おもしろいよ！
— Masatomo Nakano (@masatomon) 2010, 2月 24私は名前が違うだけ派 RT @sugamasao: なんか、BDDってTDDだとテストだと誤解されちゃうから名前変えた方が良くね、みたいな話だと思ってたんだけど、使ってるニュアンスとかを見るとストーリーテスト的な感じのテストを指しているような気がする。後者が正しいのだろうか。
— とみたまさひろ (@tmtms) 2010, 2月 24BDD:「バカ！でも…大好き」
— とみたまさひろ (@tmtms) 2010, 2月 24品質が測れるって言っている人たちは、品質の測り方を知ってるんだから、それで測ってればいいんじゃね？ それが私の思う品質かどうかはわかんないけど。というか、たぶん違うと思うけど。
— とみたまさひろ (@tmtms) 2010, 2月 24開発側がより良いものを求めて開発手法を変えたせいで、今までの測り方じゃ測れなくなったっていうんなら、また新しい測り方を定義すればいいだけでそ。
— とみたまさひろ (@tmtms) 2010, 2月 24最終的に良いものができるようにはなったのはいいんだけど、それじゃあ測れないから今までのやり方で悪いもの作ってよ〜...ってのはやだな。
— とみたまさひろ (@tmtms) 2010, 2月 24