WISH2010の一般推薦枠にTogetterがノミネートされています。よろしければ投票をお願いします。→こちら

お気に入りしたユーザ

  • yoshiori
  • ikasam_a
  • ukstudio
  • kayakaya
  • suchi
  • kakutani
  • _dot
  • nagiler
  • kkd
  • skoji
  • haru01
  • yujiorama
  • sugamasao
  • nobeans
  • kenchan
  • idesaku
  • emeitch
  • Felio
  • ursm
  • yanchi
  • taru
  • matsukaz
  • repeatedly
  • monjudoh
  • gom
  • ymkz303
  • sumim
  • yadokarielectri
  • Qiez
  • TrinityT
  • regtan
  • hayato_1980
  • mitarai

まとめられたつぶやき

  • 恋 したい
    ayumin
    2010-02-15 00:32:58
  • なんか「テストファースト」って言葉に2種類の使われ方があって、混乱するなぁ…… テスト手法のテストファーストと、開発手法のテストファーストはわけるべきだよなぁ
    yoshiori
    2010-02-15 00:43:52
  • 「TDD はテスト計画をせずにテストしてしまうから……」とか「品質管理のためには……」とか言われるとなぁ TDD はあくまで"開発"手法であって、テスト手法では無いんだよね。もう、TDDで品質があがるって啓蒙するの止めちゃえば、いっそ変な誤解が広がらないんじゃないかなぁ。
    yoshiori
    2010-02-15 00:47:13
  • TDD は開発者が不安を無くすためにやっているので「品質は担保していません!!」(本当はその不安を無くしてるおかで品質があがってたりするんだけども) でいいと思うんだけど、乱暴かなぁ‥‥
    yoshiori
    2010-02-15 00:49:58
  • @yoshiori 品質が「あがっている」と「担保している」は微妙に違いますよね
    ayumin
    2010-02-15 00:51:36
  • 不安が無くなってるからリファクタリングが出来たりして結果として品質は上るから、どうしてもみんな品質の話しをしちゃうんだけど、そのせいもあってTDDでやってればテストイラネ的な勘違いする人が出てきちゃってゴチャゴチャになるんだったら「品質の話しはしてねーよ!!」て良いんじゃないか?
    yoshiori
    2010-02-15 00:52:15
  • @ayumin 違うんだけど、「品質あがるよ!」って言っているだけなのに「それではテストとして不完全だから」とか、テスト手法と開発手法をごっちゃにしてしゃべられちゃったりするんですよね><
    yoshiori
    2010-02-15 00:55:48
  • @yoshiori そうですねー自分もたまに勘違いしちゃうことがあってついこないだも痛い目にあいました
    ayumin
    2010-02-15 00:57:12
  • @yoshiori そりゃBDDを提唱してる人が言ってることじゃん?
    lchin
    2010-02-15 00:58:10
  • @lchin うん、そうなんだけど、名前変えて逃げるのはイヤだから、乱暴かもしれないけど、「品質の話しはシテネー!!!」って言い切っちゃってもいいのかなぁって
    yoshiori
    2010-02-15 01:00:28
  • @yoshiori フェーズとして違うのに、テストっていう単語の立場がややこしいから発生する問題ですよね。実際には全くややこしい話じゃないのに。さっきのTweetの内容は適切だなって思いますよ。
    Iori_o
    2010-02-15 01:01:41
  • 風が吹けば桶屋が〜理論に基づくと、開発プロセス上のあらゆる活動は全て『コスト』軸への射影をベースとした議論に還元できる。同様に『品質』軸への射影として議論することもできる。でも、無理矢理そういったスーツ的軸上で議論を展開してみても実質的なメリットはなくて、むしろ弊害しかないよね。
    nobeans
    2010-02-15 01:01:43
  • むしろTDDという開発手法についてはききあきた感があるから、そろそろあらためて品質保証のためのテストという話をききたいししたいなぁ とか思った
    ayumin
    2010-02-15 01:02:03
  • ATDDってのもあった気がするけど、単語自体がメジャーにならなかった感がある。
    Iori_o
    2010-02-15 01:05:02
  • でも、どちらにしろテストの粒度は違うんだからそこを意識してればいいと思うんだけどな。
    Iori_o
    2010-02-15 01:05:55
  • @ayumin 「品質」を「保証」するのか。うーん、なんていうか、まずその品質を屏風から出さないとなー、という感じで、なかなかそちらに踏み込む心の力を蓄えられないなあ。
    moro
    2010-02-15 01:07:54
  • TDDなんてプログラマのプログラマによるプログラマのための開発手法なんだから、チームでとか言わずに、どんどん個人レベルでやったらいいんじゃないのかな。キーボードにHHK使うと効率が良い、とかと同じレベル。という極論。(ちなみにそんなにバリバリなTDDerでは無いです。試行錯誤中。
    nobeans
    2010-02-15 01:09:06
  • @moro 品質って何?見たいな話をきちんとした後でないと、その「保証」っていうところまで考えにくいですよね。
    ayumin
    2010-02-15 01:09:42
  • Webアプリ・サービス系だと品質保証ってそもそもなんぞ?なところが多い気がするな。開発者がこんぐらいやっとけばいっかーみたいな。
    ukstudio
    2010-02-15 01:13:58
  • @ayumin JISとかISO的な定義もありますけど、それをプログラミング的な腕力で解決すること自体の可否と是非も考えるのが大変で、それがいまやってることのスタイルに合うかどうかも微妙なので、いろいろ悩みつつ逃げてる感じ。そこへの搦め手の一つでもあるのかも < デブサミの話。
    moro
    2010-02-15 01:15:28
  • ちなみにJSTQBの用語集によると「品質(quality):コンポーネント、システム、プロセスが指定された要求、ユーザ、顧客のニーズ、期待を満たす度合い だそうです
    ayumin
    2010-02-15 01:15:51
  • @ysakaki 逆じゃない?「要件を満たしているか」というのは確認できるが、「テストが十分かどうか」は確認しにくい
    ayumin
    2010-02-15 01:19:06
  • @yoshiori 和田先生が「TDDは品質保証しない。品質向上はするけど」って言ってた気がする。チキチキTDD第2回で。
    skn9x
    2010-02-15 01:19:42
  • @ysakaki 「十分」についてkwsk。項目数? コード:テスト比? カバレッジ?(Cはいくつ?) それでほんとに「ちゃんと動くこと」担保できる? という話になるのではないだろうか。
    moro
    2010-02-15 01:20:22
  • @ysakaki テストが十分かどうかって何を持って判断したらいいか難しい気がします。要件の方が判断しやすいような。
    ukstudio
    2010-02-15 01:21:15
  • カバレッジやテストコードとプロダクトコードの比率だけじゃ判断できないし。
    ukstudio
    2010-02-15 01:21:43
  • テストによって「バグがある」ことを検出はできるけれども、「バグがない」ことを証明することは出来ない(悪魔の証明っていうの?)
    ayumin
    2010-02-15 01:24:21
  • 仕様要求を満たしているかは確認出来るけど、テスト項目が項目を網羅しているかは確認するのが難しいんだと思う。要求されている充分なテストの範囲が特定し辛い。
    Iori_o
    2010-02-15 01:25:28
  • 頭痛がひどくて起きたら、 TL 上で TDD に関する議論がされている。頭痛に少し感謝。
    t_wada
    2010-02-15 01:26:34
  • @yoshiori なるほど……。というかバグ件数を元に品質管理目標を定めるPJだとTDD入れた途端に崩壊するね。確かに品質の話はしないほうが良いかも……だけど、それだと何のためにTDDるのか説明しにくいなぁ。確かに悩みどころ。
    skn9x
    2010-02-15 01:27:26
  • 今のお仕事でシステムじゃないんだけど、事業再編後の会計システムが出力する決算の結果を経理部として承認する基準は何にするかっていう議論があるのだが
    ayumin
    2010-02-15 01:28:11
  • TDD導入時のPB曲線ってどうなるんだろう
    skn9x
    2010-02-15 01:28:25
  • 「経理マンとして胸を張って監査法人に提出できること」が完了基準にw
    ayumin
    2010-02-15 01:28:58
  • 「テストが十分か」も同じようなことではないかと。。。
    ayumin
    2010-02-15 01:29:30
  • 統合テストレベルは要件からの方が判断しやすいことも多いと思いますが単体、結合レベルはテスト手法や統計方法色々確立されてると思いますけど違うのかな?ちなみに手法以前に試験フェーズが省略されたりする方が多・・・うわ何をする!
    ysakaki
    2010-02-15 01:29:55
  • @skn9x TDD はやっぱり開発者が不安を無くすためなんだけど、極論で言えば print 文で目で確認するのがメンドイからコンピュータでも判るように 真偽で確認するようにしてますよってだけな気がするんだよね。
    yoshiori
    2010-02-15 01:31:27
  • デベロッパーとして堂々と自信をもってクライアントに提出できるかどうか
    ayumin
    2010-02-15 01:31:58
  • TDDは設計のため、というのでいいんじゃないかな。 *Tw*
    cactusman
    2010-02-15 01:32:52
  • @skn9x で、コンピュータでもわかるようにしたから目で確認するのに比べて見間違いとかも無くなったし、 CI 使えるようになっりして、そうすると継続的にテストを繰替えす事をコンピュータがやってくれて、バグを早期発見出来るようになって品質が上ってくるとかかなぁ……
    yoshiori
    2010-02-15 01:33:17
  • @t_wada 3行でまとめると「品質保証の テストは どうなった?」
    moro
    2010-02-15 01:33:27
  • @cactusman 設計もちょっと言い過ぎな気がしてきた。目で値確認するのがメンドイから真偽値で確認出来るようにしてるでも良い気がしてきた
    yoshiori
    2010-02-15 01:34:36
  • @moro ここ数年 @t_wada がデベロッパーテストのことばかり煽るのでそろそろ別のメニューが欲しくなってきたw
    ayumin
    2010-02-15 01:34:45
  • @ysakaki そこでAcceptance TDDってのがあった気がするんだけど、結局フェーズとしてのテストじゃないから粒度が大きいのが問題だったのと、普通のTDDみたいにリズミカルに出来ないのであまり一般化しなかったのかも。
    Iori_o
    2010-02-15 01:34:51
  • @yoshiori それだとテストドリブンである必要はないんじゃないの? *Tw*
    cactusman
    2010-02-15 01:35:55
  • TDD の利点 → 脱不安
    skn9x
    2010-02-15 01:36:06
  • ある程度プロダクトコードを書き終わってから *Tw*
    cactusman
    2010-02-15 01:36:25
  • 結局、手で一つづつブラウザ操作したりして、目で一つづつ確認するのがメンドくさいからテストで確認してるだけなんだよなぁ
    yoshiori
    2010-02-15 01:36:36
  • 自分も反省しているけど、同じ主張でも「TDDでのテストは一般的なテストと同じ」という誤解と、「一般的なテスト設計手法を知ってるとTDDをもっとうまく運用できるよ」というアドバイスが混在してて、品質やテストの人が前者ばかり言っているわけじゃないんだよね
    goyoki
    2010-02-15 01:37:26
  • 全称肯定命題が証明しにくいよ、バカヤローってことです。
    Iori_o
    2010-02-15 01:37:41
  • 品質保証のテストは TDD の文脈で言う「テスト」とは別に必要であり、品質保証のためのテストの価値はまったく減じていません、というのが私の意見です。 QT @moro: @t_wada 3行でまとめると「品質保証の テストは どうなった?」
    t_wada
    2010-02-15 01:38:13
  • TDD 関連の話で思ったんだけど、djUnit とかのアプローチって、あれ TDD とは相性悪いような気がした。コードの内部事情にべったりだし。
    skn9x
    2010-02-15 01:38:31
  • 何人が TL 上で TDD のことを議論しているんだろう。すごいな。興奮する。
    t_wada
    2010-02-15 01:40:04
  • TDD は設計向きだという話は、なんか納得しちゃう。大まかなロジックが確定した設計書渡されて TDD できなかった経験あるし。
    skn9x
    2010-02-15 01:40:31
  • @yoshiori だから、動作確認するのがめんどくさい、というのでもテストファーストじゃなくプログラミングファーストでもよくならない? *Tw*
    cactusman
    2010-02-15 01:43:08
  • 個人的にTDDの重要な点は「フィードバック」だと思ってるので、@yoshiori の「 print 文で目で確認するのがメンドイからコンピュータでも判るように 真偽で確認する」ってのは一理ある気がするなぁ
    ukstudio
    2010-02-15 01:43:17
  • @cactusman 不安を取り除くためだけなら、プログラミングファーストで十分? テストファーストにする利点はなんだろう。
    skn9x
    2010-02-15 01:44:21
  • @skn9x あとからでもテストコードは書けるわけで、じゃぁ、なんでテストファーストなの?というところが大事じゃないかと思ってる。 *Tw*
    cactusman
    2010-02-15 01:45:48
  • 見方を変えれば「テスト先に書いたってイインダヨ」的な視点を持ち込むこと自体が有意義なのかもしれないけど。プログラムとテスト、ぱっとわかりやすいほうを先に書くのが良いんだろうか。
    skn9x
    2010-02-15 01:45:59
  • @nsiena TDDが目指してる品質の向上ってのは。「コードの品質」でなく、「(詳細)設計の品質」だと理解してる。言い換えるなら、欠陥試験でなく、レビュー・仕様検証。
    nsiena
    2010-02-15 01:46:06
  • @ukstudio TDDの重要な点はフィードバックというのには同意。次のアクション(それが実装であれリファクタリングであれ)を起こすための支えになるフィードバックを十分に早く、必要な粒度で提供できる環境が重要ですよね
    ayumin
    2010-02-15 01:46:50
  • @yoshiori 自分は、テストコードを先に書く=オブジェクトや関数の使い方を定義する、というふうにだと考えています。 *Tw*
    cactusman
    2010-02-15 01:47:43
  • TDD による品質の向上は、進化的設計をすることによる *副作用* だと考えています。
    koic
    2010-02-15 01:48:06
  • 前プロジェクトではCIを試みた結果、スローテスト問題にぶちあたって困った
    ayumin
    2010-02-15 01:48:24
  • @ayumin そうですね。大きなところから初めようとすると「まず何をしたらいいのん?」状態になるので、小さいところから始めてフィードバックを元に次のアクションを決めるってのが重要だと思います。
    ukstudio
    2010-02-15 01:49:02
  • 会社としての品質保証はプログラムのテストより大きい概念。私が言っているテストの品質、はプログラムのテストの話です。
    ysakaki
    2010-02-15 01:49:21
  • @yoshiori テストコードを先に書くことで明確になると思いますが。 *Tw*
    cactusman
    2010-02-15 01:50:09
  • やっと最近、去年の富山でひがさんと和田さんに言われた「TDD!=テストファースト」が頭じゃなくて心で理解出来るようになってきた。
    yoshiori
    2010-02-15 01:50:29
  • 動作を確認する、というのと、動作を確認し続ける、ということの違いだと思います。自動化された self-checking なテストは確認を無人で繰り返すことができるから、CI などで「自働化」できるわけですよね。TDD の話というより自動化の話ですね。
    t_wada
    2010-02-15 01:51:22
  • @cactusman うん、でもそれ、テストファーストの話しだよね?? 今、俺はテスト駆動開発での「品質」に対する期待値的な感じ方の話しをしていたんだ
    yoshiori
    2010-02-15 01:52:40
  • 実装で悩んだらとりあえずテストを書くようにしてる。大体それで解決する。
    ukstudio
    2010-02-15 01:53:02
  • @ayumin スローテスト問題は、問題は問題で困ったちゃんだけど、移動したあとのボトルネックなのでそこは喜んでいいと思う。喜んで、心の力をためて、問題と戦う。
    moro
    2010-02-15 01:53:51
  • 「テスト再入門勉強会」をやろうやろう
    ayumin
    2010-02-15 01:54:27
  • 変な感じが。TDDのテストと仕様書のトレーサビリティは普通あまり考慮されてないと思う。仕様の検証をしたいなら、仕様分析に基づいたテストコードの再構築がいずれ必要になるんじゃないかな、と感じる
    goyoki
    2010-02-15 01:54:30
  • 自分の場合はテストファーストじゃなくて、並行or後追いでテストを逐次作っていく方式でも、十分不安が払拭できるなぁ。設計は大体概要を頭の中で描いてから手をつけるし。頭の中に収まらないような大きさの画が必要な場合は、UMLスケッチを描いてる。あ、これTDDじゃないや。
    nobeans
    2010-02-15 01:55:23
  • テスト再入門勉強会実行委員 @ayumin @ukstudio
    ayumin
    2010-02-15 01:55:41
  • @yoshiori TDDでテストを後に書くと? *Tw*
    cactusman
    2010-02-15 01:57:42
  • @nobeans テストを先に書くことが必須かというと言うとそうでもないと思います。テストが「開発を駆動」していればTest Driven Developmentじゃないかと。
    moro
    2010-02-15 01:58:01
  • この流れなら言える。 TDD Boot Camp 北陸を一ヶ月後くらいにやります。自重しない感じで一晩中 TDD や ら な い か http://kokucheese.com/event/index/1307/
    t_wada
    2010-02-15 01:58:42
  • 「テストコードがどんどん陳腐化していく問題」についてもみんなどうやって立ち向かっているのか興味がある。俺のやり方が正しかったのかも意見をききたし
    ayumin
    2010-02-15 01:58:53
  • そもそもの話に戻すと @ayumin が言っている品質保証は誰が主語?会社?プログラマ?
    ysakaki
    2010-02-15 01:59:49
  • @cactusman 例えば「不安じゃない実装なのでテスト無しで書きました。→ 機能追加があってちょっと不安な実装なので、現状のテスト書きます。」もテストファーストじゃないけど、TDD だよね??
    yoshiori
    2010-02-15 01:59:58
  • なんというか、自分の中で純粋なTDDは「OOコード養成ギブス」のような位置づけである気がしてきました。最終的にはJUnitとかを活用してプログラマの不安を極力低く保ちつつ開発していければOK. 純粋TDDはそのためのスキル養成のためのプラクティス。
    nobeans
    2010-02-15 02:00:42
  • @yanchi そのとおりだと思います。私は TDD は設計手法だとよく言っています。
    t_wada
    2010-02-15 02:00:57
  • テストコードはテストファーストでなくても書くことに意義があると思います。前任者がテスト書いてなくてもリファクタリングの過程で動作を保証するならテスト書くしかない。
    keisuke_n
    2010-02-15 02:01:13
  • @yoshiori それ、機能追加する前にテストコード書きますよね? *Tw*
    cactusman
    2010-02-15 02:01:15
  • 多分、定義としてのテストがロールによって分類されていないから色々な喰い違いが起きてるのが問題。「こうあるべき」「こうした方がいい」「こうあってはならない」が一義で語られてるのがそもそもおかしい。
    Iori_o
    2010-02-15 02:01:22
  • "型は実戦の雛形ではない"
    nobeans
    2010-02-15 02:01:23
  • @ysakaki プロダクトの提供元が提供左記に対して付するものについていっているつもりなので、プロダクトを提供する会社ですかね。会社の中の活動としてプログラマやテスターという役割とそれぞれの責任範囲があるのかな。
    ayumin
    2010-02-15 02:02:16
  • @ayumin その企画に乗った。
    Iori_o
    2010-02-15 02:02:25
  • @cactusman 機能追加する前にとりあえず現状動いてるのを壊さないように現状のテスト書くよね? この時点では実装が先でテストが後だよね??
    yoshiori
    2010-02-15 02:02:42
  • テスト再入門勉強会実行委員 @ayumin @ukstudio @Iori_o
    ayumin
    2010-02-15 02:03:32
  • テストコードを書くことは、テストを自動化するだけではなくて、テストを明確化する意味もあると思う。ってまぁそんなことをまえが言うなといわれそう。テストコードはメモ
    keisuke_n
    2010-02-15 02:03:33
  • 俺は「開発フェーズが進むにつれてテストコード(とデータ)が壊れていくのか?どうのようにその役割を変化させていくか?それを食い止めるにはどうすればいいのか?について泥臭い話をしますね
    ayumin
    2010-02-15 02:05:19
  • じゃあどうしたらいいの?っていうと主語がはっきりすれば解決すると思ってる。 それ以外で問題になるとしたら政治が絡んでくるからだろ。
    Iori_o
    2010-02-15 02:06:02
  • 深夜のテストTL過ごすぎるぅ
    ayumin
    2010-02-15 02:06:05
  • で、そもそも言いたかったのは、テストが先でも後でもいいんだけど、テスト駆動開発で品質の話をしだすと、無駄に品質管理厨を呼んじゃうから「品質の話しはしねーよ!!」って言っちゃっていいかなって事です。
    yoshiori
    2010-02-15 02:07:26
  • @Iori_o ロールによる分類はすごく大事ですね
    t_wada
    2010-02-15 02:07:26
  • @yoshiori 議論のために敢えてつっこむけど、そういうケースって品質にかかわる話になるんじゃないの? *Tw*
    cactusman
    2010-02-15 02:08:20
  • @ayumin ですよね。品質保証と言えば普通会社組織として、ですよね。毎回プロジェクト任せで品質が一定しない、ということだと品質が管理されているとは言えないから、何らかの方法論に乗っとって、という感じですかね。品質保証するための品質管理。
    ysakaki
    2010-02-15 02:08:29
  • この流れなら宣伝。デブサミでRSpecやxUnitとはちょっと違うレイヤでTDDするためのフレームワーク、Cucumberの話をします。概要と、1.5年使って見えてきたことについて。空席ありなのでみんな来てね!! おやすみなさい。http://bit.ly/aWBuVe
    moro
    2010-02-15 02:08:40
  • @yoshiori 「テスト」という言葉が受け手によって違うように、「品質」という言葉も広すぎるんでしょうね
    t_wada
    2010-02-15 02:08:43
  • TDDのテストって先付けでも後付でも結局「プログラマが頭で意識できている実装仕様」を確認するためのものだよね。で、品質のテストっていうのは「品質特性を満たしているか」を確認するためのもの(だと思ってる)。
    nobeans
    2010-02-15 02:09:11
  • もちろんプログラマは品質特性に関する点もそれなりに(ベテランであるほど比率は高い)意識してるので、結果的にTDDのテストを品質保証に流用することも部分的には可能。でも、当然不十分。目的が違うのでそれは必然。プログラマ、悪くない。
    nobeans
    2010-02-15 02:10:06
  • @ukstudio お、でも乱暴な気もするんだよねぇ
    yoshiori
    2010-02-15 02:10:28
  • というわけで、TDDの文脈では、品質は無視して語らない、もしくは、明示的に放棄するのに一票。
    nobeans
    2010-02-15 02:10:44
  • テスト書いて戻ってきたらテストとソフトウェア品質と品質保証の話がおもしろそうなことになってる。
    sunaot
    2010-02-15 02:10:56
  • @cactusman うーん、開発の手法で無駄に「品質があがります!!!」って言うのも逆に宗教ぽくて怪しいからしなくても良い気がしてる
    yoshiori
    2010-02-15 02:11:12
  • なぜそのテストをするのかの意義とか目的が、テストコードだけでは伝わりにくい場合もある。 RT @keisuke_n: テストコードを書くことは、テストを自動化するだけではなくて、テストを明確化する意味もあると思う。ってまぁそんなことをまえが言うなといわれそう。テストコードはメモ
    kerokerokero3
    2010-02-15 02:11:33
  • @uncorrelated 仕様を煮詰めるためにプロトタイピング的に検証しながら設計していく。半ばその副産物として最終成果物につながるコードが生成されていく。なので、結果的にコードの品質も上がっているだけ。(続
    nsiena
    2010-02-15 02:12:13
  • @yoshiori いやー、でもTDDは品質を保証するものじゃないからなー。結果的にTDDでコードの質は上がるとは思うけど、品質厨の言う「品質」とは違う気がするし。
    ukstudio
    2010-02-15 02:12:25
  • TDD のテストはそのとき自分がやりたいと思っていたことや、そのときの自分の理解を形にしたもので、それが他の人の目から見て正しいのかどうかはまた別の話なので、コードレビューや他の人の視点は必要です
    t_wada
    2010-02-15 02:12:25
  • 承) なので、QAのためのテストとかの一部は担うことになれるけれど、本質的に、目的もスコープも扱う範囲も違うだろうという理解。という表明でした。
    nsiena
    2010-02-15 02:12:36
  • @t_wada 「結果として品質が向上します」って言っているのに「品質を担保してる」と捉えちゃう人が出てくるので、逆に「品質の話しはしねーよ!!」って言っちゃったほうがいいのかなぁと……
    yoshiori
    2010-02-15 02:12:46
  • @yoshiori ただ、TDDとは別に品質保証については考えないといけないとは思うけどね。
    ukstudio
    2010-02-15 02:12:49
  • TDDと品質の話おもしろいなぁ。確かにテストは必ずしも品質を向上させるための手段ではないんだよね。テストは基本的に抜けがあるものだし。
    keisuke_n
    2010-02-15 02:13:26
  • まぁTDD=テストじゃないのはわかってていってるけど(^^;。
    keisuke_n
    2010-02-15 02:13:50
  • とりあえずテストの自動化と TDD がまだ混同されてたりするところが道のりの遠さをかんじさせるよね。
    sunaot
    2010-02-15 02:13:54
  • でも、最終的には何らかの形で品質向上に寄与しなくてはいけないと思うのよ。それは設計にフィードバックされてtestabilityが高くなるでも、リファクタリングしやすくなるとかでもいい。
    Iori_o
    2010-02-15 02:14:49
  • @yoshiori 俺が「結果として以前の自分よりミスが少なく、『品質』が上がっているだろうという定性的な実感がある」とか言うのは、やっぱり良くないのかな…
    t_wada
    2010-02-15 02:15:23
  • 仮に資源とならずに捨てるのであってもぼくは TDD で開発すると思う。むしろ取り上げられると他のやり方で設計する自信というのがない。設計書止まりの SE とか超人だわ。
    sunaot
    2010-02-15 02:15:35
  • @yoshiori そうするとTDDの意味論に話が転じちゃいません?それならやらなくてもいいよ、ってなりそう。
    Iori_o
    2010-02-15 02:15:56
  • 実はTDD/BDD、その他自動テストと言われているもののノウハウは私は経験不足のところがあって、自動化しにくいテストをどう扱うかという部分にちょっと興味がある。例えばGUIやハードが絡むものなど...
    keisuke_n
    2010-02-15 02:16:31
  • この速さなら言える!! 今のような話しをするどうは別としても、この発表の資料を作ってる時に出た呟きから発展したのはまちがいないので、みんな来てね!! (残席あり) http://d.hatena.ne.jp/Yoshiori/20100127/1264570722
    yoshiori
    2010-02-15 02:16:37
  • 東京Ruby会議#03では今のようなテスト関連の話題について@moroがデブサミでいえなかったことが爆発するとおもうので期待しているといいよ
    ayumin
    2010-02-15 02:18:11
  • ふむ。デバッグモードでオブジェクトの中身見るのがめんどくさいからテストに任せてるだけっちゃだけだな。楽をした結果が TDD。
    onk
    2010-02-15 02:18:27
  • @smorisaki 同意です。TDDで書いたテストを、単体テストとして妥当かレビューするプロセスをうまく回せると、テスト部隊との相乗効果がかなり出そうですよね
    goyoki
    2010-02-15 02:18:31
  • TDD の「テスト」は、作った後の下流工程の品質テストじゃなくて、上流工程の仕様・実装検証という理解。と言い換えても良かったかもしれない。
    nsiena
    2010-02-15 02:18:35
  • @Iori_o まぁ、スーパーハカーなら TDD やらなくて良いと思いますもん。寧ろ、今、手探りでプログラミングしてるけど、もっと良いプログラミングのしかたがあるかなぁって思ってる人にこそ薦めたいので
    yoshiori
    2010-02-15 02:19:07
  • もしかするとこの手の話をする時にTDDよりもBDDの方が理解しやすいかもしれない、と最近思ってる。
    keisuke_n
    2010-02-15 02:20:00
  • 怠惰で傲慢で短気だからテストを書く。
    t_wada
    2010-02-15 02:20:17
  • @sunaot そもそもの観点が違うのに"テスト"って単語で括るからですよね。って話からBDDの人も言ってた気がします。
    Iori_o
    2010-02-15 02:20:43
  • @Iori_o そうなんですよね。でも TDD て響きが好きなんですw (あと知ったときの衝撃度的に TDD に愛着が。
    sunaot
    2010-02-15 02:21:44
  • @t_wada 受け取り方の問題だと思うんですが、現状、そういう誤解が世界的に一部で発生しちゃってる事のも事実なので、なんというかガツンと極論言っちゃう方がいいのかなぁと
    yoshiori
    2010-02-15 02:22:05
  • @yoshiori 私が講演を大体の場合「テストの再分類」から始めるのは、そういう誤解を一つ一つ解いていきたいという思いがあるからです。
    t_wada
    2010-02-15 02:23:40
  • @yoshiori でもそれとは別に、「品質の高いコードを書きたい」という思いで僕の講演に来てくれた人に対して「TDD は品質とは全く関係ありません」とは言えない。僕の実感ベースの話をしてしまいます。極論で突き放すことができないのは、僕の甘さなのかもしれません。
    t_wada
    2010-02-15 02:25:26
  • そういや、BDDって言葉あまり使われないね
    ukstudio
    2010-02-15 02:26:21
  • @t_wada いや、和田さんがそうやって丁寧に説明してくれる現状がある事を知ってるからこそ、俺のポジションだったら極論言っちゃってもいいかなぁと感じてるんです>< まさに3周目の特権
    yoshiori
    2010-02-15 02:27:14
  • 「一回で正確な設計が行えれば、修正する必要はないよ」
    Iori_o
    2010-02-15 02:27:25
  • @yoshiori テストコードとはアプリケーションの動作だから、その動作を意図しようがしまいが、自動テストを実行することで逸脱しているかどうかを検知できる。テストコードとプロダクトコードが無矛盾にすることで変更に対して強くなり、リファクタリングも行いやすくなる、かな? *Tw*
    cactusman
    2010-02-15 02:27:43
  • テストが無いのにリファクタリングする勇気が持てません。
    Iori_o
    2010-02-15 02:29:39
  • うーん、俺が TDD でやってるのって、正直にいっちゃえば、コードを変更した時に(リファクタリングも機能追加も)確認を一個一個、手と目を使ってやるのがメンドいからなんだよね。だからリファクタリングが無いなら TDD 無くていいの
    yoshiori
    2010-02-15 02:30:53
  • 本音を言うと設計手法とか考えて TDD はやってないんだなぁ。それがダメなんだろうけどwwww
    yoshiori
    2010-02-15 02:32:11
  • ホント、print デバックとかブラウザで一々確認とかするのがメンドイだけなんだよね
    yoshiori
    2010-02-15 02:33:17
  • @yoshiori 別にダメではないと思う。自分の怠惰を経てなお残ったのが TDD なら、手と心に馴染んだということでしょう。設計であるかどうかはむしろどうでも良いと思います。
    t_wada
    2010-02-15 02:34:03
  • こんな時間に何人もで TDD の議論ができて嬉しい。時代は変わって来ている。
    t_wada
    2010-02-15 02:36:04
  • 品質を保証しない、という定義だけに頼るのは危うい気が。一般的なテストでも品質保証を目的としないテストはあるし、設計改善のためのテスト、回帰テストなんかもある。一般的なテストと並ぶもの、ではなくて、一般的なテストに含まれない特殊なものと紹介した方が誤解が少ないような
    goyoki
    2010-02-15 02:36:24
  • TLにTDDやらアジャイルやらの話題が飛び交うたびに思うことは「仕事でやってる以上、正しいのは生産性が上がるかどうかじゃねー、"生産性が上がる"と金だす側が納得するかどうかだ」とか思う今日この頃
    normalian
    2010-02-15 02:36:29
  • 色々めんどくさいからテストという言葉は使いたくない。かと言って BDD は説明がさらにめんどくさい。そこでアサーションですよ!
    ursm
    2010-02-15 02:36:30
  • @goyoki むしろテストという言葉を離れた方が良いという考えですか?
    t_wada
    2010-02-15 02:37:14
  • 実装のためのテスト、とか実装作業の延長線上のテストで、品質保証を目的としない、なんて説明がいいと思う
    goyoki
    2010-02-15 02:37:34
  • あとはやっぱり TDD で書くと一つの事に対する実装の繰り返しになってるとかは有るんだけど、それがあるからやってるわけじゃ無いんだなぁ……
    yoshiori
    2010-02-15 02:37:42
  • @normalian それも一つの見識ですねー
    t_wada
    2010-02-15 02:38:32
  • TDD/BDDと仕様書、実際のコードとのリンクができるようになると、いろいろ面白くなると思うんだけどなぁ。
    keisuke_n
    2010-02-15 02:39:34
  • @t_wada いえ、テストも色々あるのでテストと分類してもいいと思いますが、→みたいな継ぎ足しをしたら誤解が少ないかなと思いました >実装のためのテスト、とか実装作業の延長線上のテストで、品質保証を目的としない
    goyoki
    2010-02-15 02:39:47
  • @ukstudio C/C++ じゃないっけ。テストより好きですよ僕。
    onk
    2010-02-15 02:40:01
  • @t_wada なんか今の言葉で気持が楽になりました。そうですよね、僕の手に馴染んだ TDD の説明をすればいいんですよね!!
    yoshiori
    2010-02-15 02:40:12
  • @normalian それが政治が背景になる部分だと思うんですよね。ランニングコストを考えるとTDDでやっててくれた方がいいと思うんですが、工数とか予算を考えると最終的に安心の為だけにそんなことするな、になってしまう。
    Iori_o
    2010-02-15 02:40:24
  • だからこそ、TDDで開発することでどういう形でも何かに寄与する必要があるって考えに至りました。
    Iori_o
    2010-02-15 02:41:40
  • @goyoki なるほどです! これからもいろいろ教えてください。
    t_wada
    2010-02-15 02:42:03
  • しかし、こんなにTDDで盛り上がるなんてすごいな。
    Iori_o
    2010-02-15 02:43:42
  • @Iori_o @t_wada 「TDDできる開発者にTDDやらせた方が生産性が高い」ことは事実だと思いますが、開発プロセスやらを規定したり、開発をマネージメントする人間に対する理解が必要だと思います。顧客側からすると「安く良い物を作ってくれ」以外はどうでも良さそうですし…
    normalian
    2010-02-15 02:45:39
  • 正直、TDDやらアジャイルはいい感じだと思いますが、「TDD→開発者がTDD出来るように教育するのが大変」だし、「アジャイル→お客orマネージャーにこっちの方が良いと理解させるのが大変」なので、普及には時間がかかりそうだなぁと。個人的にはTDD・アジャイルすきなんですけどね
    normalian
    2010-02-15 02:47:47
  • 自分の中で近年の指針はけっこうここにある。残念ながらセッション見てないけど、それでも何度となく見返した。 http://kakutani.com/20090213.html#p03
    sunaot
    2010-02-15 02:53:10
  • TDDが盛り上がっとる。なるほど、TDDはプロセスというよりもアーキテクチャなのかもしれないな。
    yusuke_arclamp
    2010-02-15 02:53:20
  • @normalian 誤解や先入観を解いて一歩一歩進めるしかないなぁと考えています。また、 TDD は開発プロセスとは直行している個人スキルなので、アジャイルとは切り離して話すように心がけています。
    t_wada
    2010-02-15 02:56:10
  • @t_wada 俺はこのエディタ使うよ、ってのと同レベルにTDDで開発するよ、っていう選択肢がくるようになればいいんですけどね。
    Iori_o
    2010-02-15 03:02:00
  • 賛成。次の段階はレポジトリにテストコードコミットしちゃうけど害はないから許してね。ですね。 RT @Iori_o: @t_wada 俺はこのエディタ使うよ、ってのと同レベルにTDDで開発するよ、っていう選択肢がくるようになればいいんですけどね。
    sunaot
    2010-02-15 03:04:23
  • @t_wada 私もそれが一番の近道だと思っています。アジャイルは人間同士のコミュニケーションに依存する部分が従来開発より遥かに大きく「考え方を普及させて誤解を解いていく」のが一番かなぁと。TDDは仰るとおり、個人スキルですよね。「後身の育成が大変だよなぁ…」とか思ってます(汗
    normalian
    2010-02-15 03:05:46
  • 言語の勉強も大事かもしれないけど、コメントの書き方もちゃんと教育するべきだよな。余計なコメントは見たくないし、必要なことが書いていないのも腹が立つ。仕様書に戻るとまた違うことが書いてある。
    Iori_o
    2010-02-15 03:07:32
  • 「日々のテスト活動」「最新のコードを毎日ビルド」「過去の全ストーリーを毎日テスト」「UnitTest とは別」 咳さんのデブサミ2008資料より。 http://tinyurl.com/yejdboj
    sunaot
    2010-02-15 03:12:33
  • コードと仕様書が違う場合、コードが運用で使われている場合はコードが正、コードが運用で使われていない場合は仕様書が正。とリトマス紙のようにいかないのが現実なんだよな。探偵業をして確認すると、新たな要求が出て加味し直して欲しいとかでてきて、どちらでもないのが新たな正になったり。
    koic
    2010-02-15 03:12:40
  • TDD実施時には。当然ながら、一定水準の品質保証ではなくて。実は、品質向上もあまり視野には無くて。もっぱら、コード修正時のデグレード防止を目的にしていることが多い。上げるのではなく、下がらないようにする。一見言い換えているだけに見えるかもしれないけれど、これは全く違う。
    nsiena
    2010-02-15 03:21:56
  • @nsiena それは違うように感じます。TDDでは、書いたコードがきちんと動くかチェックするのもテストの大きな役割です
    goyoki
    2010-02-15 03:28:51
  • @goyoki 感覚としては。「書いたコードがきちんと動く」のも含めて、です。テストケースとして書き下したことが正しく守られ続けている == 当初の品質からデグレードしないことを保証し続ける、という意味合いで。
    nsiena
    2010-02-15 03:34:17
  • @goyoki あ、あと。リファクタリング/ビッグリファクタリングの過程で実装設計の品質を向上させていく、は TDD の範疇だと思ってるです。さっきのはコードを書き起こしていく/小さなリファクタリングの時に持ってる意識だったかも。
    nsiena
    2010-02-15 03:37:09
  • @nsiena 「デグレードしないこと」と「書いたコードがきちんと動く」は同じものではないです。これからまさに書くコードがきちんと動くかどうか保証する、例えば新規実装中にコーディングミスしたらそれを即座にフィードバックする、というのもTDDの役割ということです
    goyoki
    2010-02-15 03:42:33
  • @yoshiori TDD とテストファーストの話なのかなと判断します。先にテストを書いたからといって TDD になるわけではないし、あとから書いてもそのテストを第一歩めの礎にしてリファクタリングを行いコード/設計を改善していく回転を回し始めれば TDD だと思います。
    t_wada
    2010-02-15 03:51:41
  • @goyoki おっしゃるとおりです >< 元のつぶやきは、あたしが実施する時により強く意識するのは、というつもりだったので。「正しく動くように」は前提として当然担保されているものとして省いちゃってたです。テストへの仕様変化の反映、テストの改善などもサイクルに含むものとして。
    nsiena
    2010-02-15 03:55:29
  • @yoshiori 動作する綺麗なコードへの道筋が大事。黄金の回転の4象限。ひとつずつ、すこしずつ。一度に相手するのはひとつ。すばやくまわす。最初のユーザは自分。不安をテストにする。 TDD は才能ではなくスキル。
    t_wada
    2010-02-15 04:00:29
  • @t_wada TDDでは動作するテストコードからの素早いフィードバックと開発のリズムが大事だと思っていますが、その実装としてやはりよくできた統合開発環境のそんざいが前提になりますか?またコード以外のプロダクトに対してTDDを適用可能でしょうか?
    ayumin
    2010-02-15 04:07:03
  • テストファーストも TDD も、テストという語彙の是非は置いておいてきちんとした名前になっていると思うんだけどな。
    koic
    2010-02-15 04:08:39
  • @t_wada 僕も富山の時以来、テストファーストとTDD の違いを考えるようになって黄金の回転こそがTDDの本質だと思う様になりました。そしてそれはプログラマのためのテストであって品質を担保するのとは違うんだと(結果としては品質向上に繋がるんだけど)
    yoshiori
    2010-02-15 04:09:47
  • TDDはアジャイルと切り離して考えた方がいいと思う。ウォーターフォールでもTDDは出来ると思うのよね。
    ukstudio
    2010-02-15 04:11:09
  • テストファーストはテストを先に書くという、手を動かさなくても分かりやすいものであるのに対して、TDD は Driven という手を動かさないと感じられない、分からない、座学だけでは納得させづらいものだと思う。
    koic
    2010-02-15 04:14:59
  • @ayumin IDE の存在は前提ではありません。どのような道具であれ TDD はできます (とはいえ IDE は強力な道具です)。 またコード以外の対象に対して TDD 的なアプローチは可能ですし、そこまでいくと汎用の仕事術 (GTD や PDCA) とあまり変わらないですね
    t_wada
    2010-02-15 04:23:20
  • なんか「品質の話しはしない!」「テストファーストにこだわらない」XPの4つの価値の一つである「勇気」のための不安を無くす為の TDD とそこからなる黄金の回転というすごく刺激的な TDD の資料が書けそうな気がしてきた
    yoshiori
    2010-02-15 04:23:20
  • プログラムファーストでも TDD できるけれど。それはテストファーストよりもハードルが高い気がする。 #TDD
    nsiena
    2010-02-15 04:25:01
  • 前提として。TDD でのテストは。どう実装されているかでなく、どういう実装仕様であるべきかが書かれているべき (あるいは、そこに漸近的に収束していくべき)。 #TDD
    nsiena
    2010-02-15 04:25:32
  • プログラムファーストだと。今そこにあるコードに引きずられてしまう危険性が相対的に高まりやすい。または、テストケースの書き起こしを後回しにして、まとめて書いてしまうかもしれない。どのようにあるべきと考えたのかを忘れやすくなる。 #TDD
    nsiena
    2010-02-15 04:26:03
  • そうならないためには。あるべき実装仕様を表すのだという鋼の意志と、考慮した重要な仕様を一切忘れないという頑健な記憶力とが求められる。あるいは、それを避けるために細めにテストケースを作っていく几帳面さが。そんなよに思う。 #TDD
    nsiena
    2010-02-15 04:26:45
  • なので、一般的には。TDD はテストファースト、と教条主義的に刷り込むところから始めてよいのではないかしらん。型を崩すのは、その呼吸を理解してからでいい。 #TDD
    nsiena
    2010-02-15 04:27:26
  • @yusuke_arclamp アーキテクチャやプロセスな一面もあると思うんだけど、開発手法だっていう部分がまず根底に無いとブレちゃう気がするんだよね。品質管理や設計とかに行く前に
    yoshiori
    2010-02-15 04:30:56
  • もう、俺の師匠として @kakutani@t_wada の名前を出さない方がいいのかなぁ…… リスペクトしてるから感謝の意味も含めて出すようにしてるんだけど、二人の名前を出して二人に迷惑かかっちゃってもアレだしなぁ
    yoshiori
    2010-02-15 04:32:22
  • 目で確認するのが面倒だからテストに任す ってのは俺には合ってるなぁ
    fistfvck
    2010-02-15 04:34:23
  • テストを書いてから実装する、が最大の焦点ではなく。テストを担保として漸次的に実装・改善していく、が最大の焦点。テストファーストは前者の観点。TDD の本質は後者。だと思ってる。
    nsiena
    2010-02-15 04:35:42
  • @fistfvck TDD のサイクルは実は Think -> Red -> Green -> Refactor (The Art of Agile Development より) なので、 Think が P に相当し、小規模でぐるぐる回す感じでしょうか
    t_wada
    2010-02-15 04:35:58
  • @ayumin 俺が初めてペアプロで TDD を教わった時は emacs で Ruby でした!!! まぁ、emacs は 世界だとかいう話しはおいておいて < 統合開発環境
    yoshiori
    2010-02-15 04:36:49
  • そういえば今日の TL に咳さんがいればいろいろ示唆に富む言葉がもらえたんじゃないかなぁ
    t_wada
    2010-02-15 04:38:25
  • この熱を持ったまんま週末のデブサミにのりこみたい!!
    yoshiori
    2010-02-15 04:38:35
  • @t_wada 実は俺の中では「石井さん」→「和田、角谷」→「俺」の3周目でもあったりします
    yoshiori
    2010-02-15 04:39:46
  • @yanchi ありがとうございます。でも頭痛のおかげでこの TL に出会えたのでよかったです。薬飲んで寝ます…
    t_wada
    2010-02-15 04:41:17
  • あんまり品質の話ししてると俺、実装終わった機能のTDD用のテストコード消しちゃうぞ!!(不安だからこっそりとっておくけどw)
    yoshiori
    2010-02-15 04:41:52
  • @t_wada そうなんですか! Thinkがあったなんて知らなかったです…。
    fistfvck
    2010-02-15 04:42:00
  • @yoshiori 石井さんが教えてくれたものは本当に多く大きかったです。それを自分なりに咀嚼して伝えられているなら嬉しいです。
    t_wada
    2010-02-15 04:44:21
  • @yoshiori 私はむしろ消したいですねえ。少なくともクラス単位のテストは邪魔になることの方が多いと感じます
    ursm
    2010-02-15 04:45:01
  • @fistfvck TDD って何も考えてなくね? という問いに対する答えのひとつですね。 TDD を行うときに暗黙のうちに考えているフェイズを明示したという感じでしょうか。
    t_wada
    2010-02-15 04:46:03
  • @t_wada 去ってしまった者たちから受け継いだものは さらに『先』に進めなくてはならない!! この「TDD」は破壊しない!
    yoshiori
    2010-02-15 04:46:04
  • @ursm テストのリファクタリングが出来れば一番なんだけどね><
    yoshiori
    2010-02-15 04:46:50
  • インターフェースをあまり考えずに書いてるせいなんだろうけど、そんなこといちいち決めてられるか。API はコードから導出されるんだよ!
    ursm
    2010-02-15 04:47:26
  • @ursm @yoshiori 私も開発のスピードや安全性、不安克服を妨げない範囲内でのテストを減らしたり資産運用することを最近専ら研究しています
    t_wada
    2010-02-15 04:48:33
  • 結局 TDD で克服する不安は XP の 4 つの価値の一つ「勇気」を掴む為の後押しをしてくれるものだと 厨二的に叫びたい!!!
    yoshiori
    2010-02-15 04:50:18
  • あ、(テストによる)フィードバックも、(コードとの)コミュニケーションも(一つの事を相手にする)シンプルさも含んでるんだけどね
    yoshiori
    2010-02-15 04:51:55
  • twitter が一番 TDD のサイクルを乱すのだけは間違いない。
    sunaot
    2010-02-15 04:52:13
  • @ursm 一人の優秀なプログラマ(またはよく訓練されたプログラマたちの)責任と権限に収まる範囲のモノをつくっているうちはそれでいいのだろうけどね。。。
    ayumin
    2010-02-15 04:53:27
  • @ayumin おっしゃるとおりだと思います
    ursm
    2010-02-15 04:54:59
  • おれも、@t_wada さんに教えてもらった世代に入るのかなー。gihyoの動画で最初に学んだわ。
    ukstudio
    2010-02-15 04:55:07
  • TDDをやろうと思い立ってもテストコード自体のレビューが不完全で、結局プロダクトコードを追随するだけの無意味なユニットテストが山のように量産されていくという悲惨な状況を経験した
    ayumin
    2010-02-15 04:55:23
  • ということで俺はプロダクトコードの変更に追随しきれていないユニットコードをカバレッジで定量的に測定するとともに、それをメンテし続ける工数がどんどん上がっていきながらも、結合テスト消化率が上がってユニットテストがダメダメなはずなのにモノは完成に近づいている
    ayumin
    2010-02-15 04:59:22
  • 品質って何?なんなの? QWONのこと?もう頭が爆発しそう
    fistfvck
    2010-02-15 04:59:49
  • という奇妙な状況を明らかにした上で、そのプロジェクトのそのフェースにおいてユニットテストにかける工数の費用対効果が悪いことを説明して、実質的に単体テストというフェーズをフェードアウトさせたのだった
    ayumin
    2010-02-15 05:01:17
  • やっとこさテスト書いても、プロダクトコードとテストの乖離が激しくなってテストのメンテがつらくなるのでめげる
    fistfvck
    2010-02-15 05:14:57
  • 「ビヘイビア」って5文字もあるから駄目なんだよ多分
    ursm
    2010-02-15 05:25:27
  • @ursm かと言って「振る舞い」と言われてもピンとこないです…
    fistfvck
    2010-02-15 05:26:24
  • @fistfvck そうなんですよねー。「テストって言うけどいわゆるテストじゃないです」って言い続けるしかないんですかね
    ursm
    2010-02-15 05:32:14
  • BDD は TDD からの名付け全般の改稿としては、結局よく分からないものになって失敗だと思う。衝撃的な概念もなくて、それ TDD でできるよで終わりそう。
    koic
    2010-02-15 05:38:58
  • BDD フレームワークで使われている語彙は良い方向に進んでいる。
    koic
    2010-02-15 05:42:06
  • BDDは実質TDDと変わらないと思ってる。TDDのテストって言葉がややこしいし、TDDで検証してるのって振舞いだよね、だったらBDDの方がよくね?って話だったはず。
    ukstudio
    2010-02-15 05:45:18
  • @t_wada なるほど なぜよく言われるTDD(Red>Green>Refactoring)からThinkが抜け落ちたか?が知りたいですね
    fistfvck
    2010-02-15 05:46:01
  • BDD という名前が付いたことが失敗で、それは QWAN であるべきなんじゃないか。
    koic
    2010-02-15 06:00:20
  • @koic TDD->BDDで回避したかった議論がTLにいっぱいあると感じているのですけどね...
    kkd
    2010-02-15 06:03:57
  • Spec Driven Development
    ukstudio
    2010-02-15 06:04:10
  • @koic BDDという名前が悪かったのか、そもそも名前を付けるべきじゃなかったのかは僕にはわかりませんが、TDDの誤解に関する問題提起や仕様に近い語彙を使うといった点でBDDは存在してよかったと思いますけどね。
    ukstudio
    2010-02-15 06:06:08
  • ATDDが日本で流行ってないのは単にユーザーストーリーがきちんと理解されて使われていないだけと感じる。ストーリーには満足/完了条件を設定するし、それをテスト//ビヘイビアという形に変換し、自動化したいという欲求は自然な流れ。
    kkd
    2010-02-15 06:06:48
  • TDDはKJ法と同じだよ、って言っても通じる人はあまりいなそう...
    kkd
    2010-02-15 06:07:55
  • TDDはよいプログラマとしての実施/思考プロセスを形式化し実現可能にしてくれたもの。だからプログラマが不安を取り除けるし、結果としてよいものができる。
    kkd
    2010-02-15 06:13:43
  • ただTDDに含まれない、もっと細かい粒度の思考プロセスもあって、それが @m_seki がいうところの「TDDではまだ粒度が粗い」だと感じている。
    kkd
    2010-02-15 06:15:43
  • @kkd 僕がこんな発言をしちゃったから BDD の時にさんざん話しあわれてたのを蒸しかえしちゃったのかもしれません>< http://bit.ly/as1xT4
    yoshiori
    2010-02-15 06:21:42
  • @yoshiori いえいえ、いいんです。つまりこの議論はまだ綺麗に終っていない、ということなので。多分二周目はもっとよい議論ができるのだと信じています。
    kkd
    2010-02-15 06:23:26
  • 僕も基本的な感覚は一緒です。 RT @kis: テストとかよくわからんので、プログラム動作確認のときのSystem.out.printlnしたものに関しては、assertEqualsに書き換えてテストとして保存している。
    yoshiori
    2010-02-15 06:24:52
  • TDDはAgileのコンテキストとは独立して語れるのは同意できるけど、自分はセットで語りたい派。なぜならTDDは漸進的開発プロセスのプログラマレベルのものだから。
    kkd
    2010-02-15 06:32:24
  • @kis 基本は不安をテストしたいので、「System.out.println した」→「値を確認したかった(不安だった)」になるので、それをテストとして書くのも TDD だと思います。
    yoshiori
    2010-02-15 06:35:37
  • @kis テストが開発のための動力源であれば、TDD だと思ってます。
    yoshiori
    2010-02-15 06:38:15
  • TDDの話とテストファーストの話と、そしてUnitTest自体の話がやっぱりごっちゃになりがちなんだな。TDDで書かれるテストは(原則として)単体テストなんだから、製品としての品質保証に不十分なのは当たり前なんだがのう。
    skoji
    2010-02-15 07:20:40
  • TDDは自動化されたUnitTestをうまく書く手法と捉えてもよいと思う。
    skoji
    2010-02-15 07:22:56
  • TDDの「テストコードがどんどんダメになってく」問題への回答は、xUTPやThe Art of Unit Testingに書かれている。異論はあるだろうけど、でもこのレベルをおさえらずに実践されているTDDが多いのではないか。
    skoji
    2010-02-15 07:25:35
  • TDDの議論も重要だけど、それとは独立してUnit Testの書き方を、独立して見なおす必要もあるのではないか。
    skoji
    2010-02-15 07:26:35
  • TDDは個人レベルの話、って意見もあるが、個人「でも」できるが、それよりチームでやるほうがずっと好ましいと思う。
    skoji
    2010-02-15 07:28:53
  • TDDはともかく、Unit Testについては、書き方も含めコーディング規約のようにチームで運用ルールを決めないと、コードのメンテナンスフェーズでの旨みがなくなっちゃう。
    skoji
    2010-02-15 07:29:05
  • Unit Testがプログラマの不安を軽減する効果があるのは間違いないが、それを強調しすぎると、自分のためだけのテストになって、そうすると陳腐化するのも速くなる。メンテナンスフェーズで、他のひとがコードいじるときに使い物にならなくなっちゃう。
    skoji
    2010-02-15 07:31:29
  • 自分のためだけにUT書いてると、せっかくUTがあるのに、簡単に「レガシーコード」になっちまうわけですよ兄さん。
    skoji
    2010-02-15 07:33:21
  • あの後に3時間もTDDの話が続いていたのか、凄いな。おはようございます。
    Iori_o
    2010-02-15 07:50:54
  • The Art of Unit Testingは、翻訳出版してもらうべく活動中です。がんばって翻訳したくなるくらい、私にはよい本なんです
    skoji
    2010-02-15 08:44:11
  • The Art of Unit TestingをAOUTと略してるのをみかけたが、ものすごく検索しづらい件。
    skoji
    2010-02-15 08:50:22
  • TAOUTと略すべき RT @skoji: The Art of Unit TestingをAOUTと略してるのをみかけたが、ものすごく検索しづらい件。
    kkd
    2010-02-15 08:57:09
  • BDDは失敗だとは思えない。曖昧模糊としたものになってしまった感はあるけど、名前をつけたこと、テストを振舞いと呼ぼうとしたことは大切なことだと思う。そのおかげでそれを前提とした話がし易くなった。
    Iori_o
    2010-02-15 10:17:57

チェックアイテム

お勧めアイテムネタ商品を追加してまとめをもっと面白くしよう!今すぐ追加?

コメント

  • fistfvck
    upd 02:33
    fistfvck
    2010-02-15 02:33:20
  • fistfvck
    upd 03:07 誰でも編集可にした
    fistfvck
    2010-02-15 03:07:27
  • grateful_dead
    RT @t_wada: TDD のテストはそのとき自分がやりたいと思っていたことや、そのときの自分の理解を形にしたもので、それが他の人の目から見て正しいのかどうかはまた別の話なので、コードレビューや他の人の視点は必要です
    grateful_dead
    2010-02-15 03:14:50
  • fistfvck
    upd 03:31 そろそろ発散した?
    fistfvck
    2010-02-15 03:31:09
  • t_wada
    遡って TDD TL の文脈であろうという発言をいろいろ足しました。問題ある場合は自由に削除してください。
    t_wada
    2010-02-15 04:10:00
  • t_wada
    競合して失われたと思われる発言を復元 (したはず)
    t_wada
    2010-02-15 04:28:48
  • t_wada
    抜けやその後の議論を追加
    t_wada
    2010-02-15 05:01:13
  • ukstudio
    俺がわかる範囲で復旧。誰でも編集できるみたいなので気になるところは直しちゃってください、すみません。
    ukstudio
    2010-02-15 10:33:47
  • t_wada
    結構復元したはず
    t_wada
    2010-02-15 11:11:18
  • Iori_o
    昨日拾ってもらってた分を追加させてもらいました。
    Iori_o
    2010-02-16 00:01:45

編集の履歴

2010-02-16 00:00:01 Iori_o さんが更新しました。
2010-02-15 11:11:18 t_wada さんが更新しました。
2010-02-15 10:43:30 ukstudio さんが更新しました。
2010-02-15 10:33:46 ukstudio さんが更新しました。
2010-02-15 06:11:58 ukstudio さんが更新しました。

ブログパーツ


幅・高さの指定を変えることでサイズを変更できます。
またsrcの中の「bc=***」で背景色を変更できます。

プロフィール

fistfvck fistfvck
@togetter_jpをフォロー

最近ログインしたユーザ

nakamiche 4k70se0 kmusiclife
Furuya3560 zvator ugnoguchi
nttsb __ebi jun1kana
NA_geek aipa_tiger jiro7771
kiyomichiyama kahein_ryaku nanashinogonbe7