TDDBC福岡に参加してきた
福岡TDDBCに参加してきた。今回で3回目の参加(1回目は東京、2回目は東北)。 3回は割と多めの参加回数だと思うけど、参加者層が地域によって違ったり、当然ペアプロする相手も違うわけでいつも違う刺激をもらってる。 今回は@mzpさんが参加するとのことなので普段使ってるRubyではなくOCamlで参加。OCaml組は2ペア(4人)いて、1日目の前半を@suerさん、1日目の後半と2日目を@mzpさんとペアを組んでやった。OCamlは初心者もいいところなので2人には大分お世話になりました。どうもありがとうございます。 コンパイルが必要な言語でTDDをやるとコンパイルがテンポを崩しがちなんだけれど、OMakeが結構よく出来ていてautotestみたいなことも出来るし、その辺は特に不自由ない感じ。OCamlの型付けの強さはなかなか慣れないけれど、コンパイルが通った時点で型の間違いがないって言うのは
開発促進のテストと品質保証のテストは別物だった件 - aike’s blog
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーを見て、TDD(テスト駆動開発)について思ったことをもう少し。 テストの分類（スライドの43ページ目）が個人的には衝撃的だった。 Developer Testing（開発促進のためのテスト） Customer Testing（進捗管理のためのテスト） QA Testing（品質保証のためのテスト） ウォーターフォール脳でアジャイル開発に手を出したときの落とし穴はここだったのかと膝を打った。それはもう何回も。 伝統的なスタイルの単体テストは３なんだよね。品質保証。で、アジャイル開発でいうところのテストファーストってやつは１のことだったわけだ。そりゃ噛み合わないはずですよ。 TDDのテストを書くトリガって、「基本的な要件だから」とか「このへんがちゃんと動くか不安だから」とかだと思うんだけど、品質管理屋の目で見るとそのやり
TDDとテストファースト => TDDのオレオレ定義と5回リロードルール - moroの日記
自分でももやもやしてるのでツッコミ希望。 考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/ TDDを紹介するときに、「TDDではプロダクトコードの前にテストを書く」という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。 TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。 別にあとから作っても*1、 自分が作ってるモジュールを使ってみたら、APIが「ねーよwww」くらい使いづらいものであると気づいたり、とか
いまさらTDDを見直す - Inemuri nezumi diary(2007-07-25)
_ いまさらTDDを見直す いまさら「フェルマーの最終定理 (新潮文庫) 著:Simon Singh 訳:青木 薫」を読んだ*1。この本はすごくいい。 この本が指し示していることのひとつは、皆、汗かいて土木作業してたってことだ。ピタゴラス、ユークリッド、…、オイラー、ガウス、…、ソフィー・ジェルマン、…、志村=谷山…。 綺麗な命題/予想を産み出した彼/彼女らは、手を動かす計算をむちゃくちゃな量やってる。 型理論によれば、型は命題で、実装は証明にそれぞれ対応する。そして、テストは、実装の仕様記述の一部に対応する。具体例を計算することはテストすることだ、と言える。 つまり、XPとかTDDとか誰かが言い始めた2000年前から、数学家はひたすらテストファーストだったってこと。証明/予想を言い終えた後は、テストの結果は焼いて捨てたから残っていない。 反論もありそうなことを敢えて言うが、私自身、テスト
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
TDD と BDD - babie, you're my home
Rails 勉強会で RSpec on Rails のセッションのとき、舞波さんが「Test::Unit(TDD) と RSpec(BDD) って本質的にどう違うの？」ってひたすら言ってて、恐らく「本質的に差はねぇなー。一緒じゃん。なら変えることないな。」と思ってたんじゃないかと思う。 ズバリ、本質的には一緒です。しかし、言い換えることが大事なのですよ。TDD の本質は、テストでなく設計にある(今は Driven の話は抜き)。TDD という言葉ではその本質を見紛うから、BDD という言い換えが重要なのです。assert_* が should_* になるのもソコ。TDD する時って、テストを書いてるんじゃなくて、仕様を書いているでしょ？。 本質的には一緒。見紛わないための、絶えず意識するための「皮」が大事なのですよ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TDD/BDDは不完全なユニットテストを招くか？