BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 振る舞い駆動開発とはツールではなく対話である

振る舞い駆動開発とはツールではなく対話である

原文(投稿日:2014/04/24)へのリンク

振る舞い駆動(BDD/Behavior-Driven Development)で重要なことはただひとつ,ツールではなく対話である – 先日のCucumberカンファレンスにおいて,Liz Koegh氏が10年間のBDDの実践に関するプレゼンテーションで述べたことばだ。
独立系のアジャイルコーチとしてJBehaveなどにも貢献のある氏は,私たちが長年にわたるBDD実践において,何か大きな誤りを犯していると考えている。しかしその一方で,私たちの現在の理解状況やここ数年で始まったいくつかの開発に対しては,非常に強い関心を持っている。

2003年にDan North氏が最初に思い付いたBDDのアイデアは,定義としてはTDDに近いものだが,システムに必要な振る舞いを記述することばとして,"テストする(test)"ではなく"すべきである(should)"を使う,というものだった。振る舞いについて,特に実例について語ることが,テストを対象とするよりも有用だということが分かった後の2006年,氏はBDDを正式に公開している。

Koegh氏が初期に犯した誤りは,"すべきである"という言葉を"しなくてはならない(must)"あるいは"するつもりだ(will)"に置き換えることで,システム要件や多くの人々の合意に近づけようとする行動だった。North氏が"すべきである"と言ったのには,実は質問や対話を活性化する意図があったのだ。

BDDを運用するコミュニティが多く犯すもうひとつの誤りは,BDDの実践を主張しながらも対話せず,BDDテストについても語らないことだ。"テストする"sという言葉が目標から取り除かれたと同時に,利害関係者やその領域の専門家に実例や振る舞い,シナリオなどについて問うことを止めてしまっているのだ。
Koegh氏は人々に対して,立ち戻って対話することの必要性を声高に呼びかける。 テストの自動化への傾倒は,あまりにも多くのシナリオ作成を要求し,対話よりもツールを重視することから,結果的に人々をスローダウンさせてしまう。ツールから一歩退いて,システムの振る舞いを広く伝えるための対話がなければBDDの効果は得られない – 氏はそれに気付いたのだ。

氏が非常に興味を持っている新概念は,複雑性を推定する方法としてのCynefinである。不確実性の多いビジネスのシナリオに着目して,そこから結果を見いだすためにBDDを用いるものだ。

氏はBDDの最大の目的でプレゼンテーションを結んでいる。

BDDとは,重要なソフトウェアを(例を使って!)記述するためのものです。

この記事に星をつける

おすすめ度
スタイル

BT