BDDの導入 - Dan North - Digital Romanticism

この記事はDan North氏の記事「Introducing BDD」を氏の許可を得て翻訳した公式版（"the official translation"）です。（原文公開日：2006年9月20日） 私は１つ問題を抱えていました。様々な環境にあるプロジェクトでテスト駆動開発（TDD）のようなアジャイルのプラクティスを用いたり、あるいは教えていると、いつも同じような混乱や誤解に行き当たったのです。プログラマが知りたいと望むのは、どこから始めれば良いのか、何をテストすれば良いのか、何をテストする必要がないのか、１つのものに対してどの程度テストすれば良いのか、テストをなんと呼べば良いのか、テストが失敗した理由をどう理解すれば良いのか、ということでした。 TDDに深く入り込むほどに、自分の道程が、言われたことをコツコツやれば徐々に上達するようなものではなく、むしろ行き詰まりの連続であると感じました

[SWIMATH2]

ほー

[Windymelt]

TDD/BDDの文書の邦訳．

[calpo]

"TDDに深く入り込むほどに（中略）行き詰まりの連続であると感じました。"〜そしてBDDへ。Given-When-Thenテンプレートの誕生。

[masakielastic2]

given-when-then

[a2ikm]

テストと設計

[aoe-tk]

BDDを要件定義に取り入れる

[matsukaz]

BDDのコツ

[twainy]

プログラマ以外がテストシナリオを書くのなら英語で書けるというのはメリットがあるんだろうね。プログラマ本人が書く分にはテストクラスだけで済ませた方が簡単

[tinsep19]

BDDは分析のための「ユビキタスランゲージ」。　As a X, I want Y, so that Z. Given B, when Y, then R

[katzchang]

JBehaveの作者による、2006年の記事。表現方法とシナリオ駆動について。