ひよっこ。

I want to…

xDDについて考える(その1)

Posted by hikaruworld : 2010 3月 16

※このブログはデブサミ後のTwitterで話題になっていた時に下書きしていたものをそのままUPしています。
先日TDDBootCamp北陸に参加して少し考えたところもあるのですが、それは別エントリに。

最近xDD(???-driven development)という言葉が色々取り上げらています。

  • TDD(Test-driven development)
  • BDD(Behavior-driven development)
  • SDD(story-driven development)
  • DDD(Domain-driven development)

※ここでTiDD(Ticket-driven development)のような技法を含んでいないのは、ちょっと方向性が違うかなと思ったためです。

デブサミでも話題になったそうで、Twitter上でも色々議論が流れているようですが、
ちょっといま忙しくてほとんど読めていないので、xDDとユニットテストに関して
少し自分の脳みそを整理してみたいと思います。

その前に@BeforeClass

まず、それぞれの単語を「誰が」「何のために」を基準に以下のように定義しておきます。
これは、xDDという単語がバズワード的に使われているのが現状でもあり(TDDとかそうですよね)、
あらかじめ定義しておかないと話が進まないためですorz..(thanks!! @t_wada)

TDDとは

言わずとしれたテスト駆動開発の略で、特定のクラス/メソッドを作成する際に、
事前に仕様プログラムを書いて、仕様検討を行いながらテストを書く方法です。
「開発者自身」が「設計に漏れがないかを確認するため」に利用します。

ex) 共通クラスAの実装を行う場合にテストプログラムで仕様を検討しながら実装を行う。

BDDとは

「振る舞い駆動開発」の略称で、そのコンポーネントやAPIがどのような挙動をすべきかを
事前に定義して、その振る舞いを実装していく手法です。
「その他の開発者」が「その機能を利用する際にどういった動きを求めているか」
を確認する目的で利用します。

ex) 外部API、Hogeの振る舞いを定義してそれに合うように実装を行う

SDDとは

特定の機能要件、つまり「ストーリー」を定義し、それにあわせて実装を行う方法です。
RubyではATDDといわれているそうですね。
「顧客」が「どういった機能を求めているか」を明確化するために実装されます。

ex) 特定の機能要件で求められる動きを確認するために行う。

DDDとは

ドメイン駆動開発の意味で、アプリケーションのドメイン単位、
つまり業務領域を対象に設計を行う手法らしいです。

が、あまりこのあたりは正確に理解していないため、詳しくは触れませんorz…

自分の考えるxDDの相対関係

以上のように、いずれのケースおいても設計のためのテストとなっています。
SDD,DDD(場合によってはBDDも)はプログラムの読めないユーザと
xDDのOutputを用いてコミュニケーションを行う必要があるため、
自然言語で「」読めることが重要かと思います。

ちなみに、私はxDDによって生成されたテストコードから
品質保証用のユニットテストを生成することは構わないと思います。

ただし、このレベルでのユニットテスト生成のコストがどこまでペイできるかの問題になるかと思います。
先日雑談をしていたときに、頻度の低い部分はインスペクションによって担保すればよいと言う話題もありました。
この場合は、定量的なテストが行いづらいのが難点な気がします。

ただ、ユニットテストとインスペクションは対であるという話があって意味合いとしては理解できます。

次に続く。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

 
%d人のブロガーが「いいね」をつけました。