ひよっこ。

I want to…

Posts Tagged ‘SDD’

xDDについて考える3

Posted by hikaruworld : 2010 3月 27

これは、前回の続きになります。

多層的にxDDを実践する

自分が考えるxDDの連携とは以下のような感じです。

また、こういった風にxDDを実践することの大きなメリットは、
Inputに対して最終的なOutputを早期に返せることだと思います。
※ここでいうOutputは実装された成果物ではなく、要求を満たすテスト仕様のアウトラインのことです。

つまり、「こういう機能が欲しいんだ」というユーザ要望に対して、
「このような仕様で行きますよ」ではなく「この動作が問題なく通れば機能は問題ありませんね」
という方法を提示します。

個人的には、要求に対応するのは実装結果ではなくその要求を満たすテストと考えています(どっかの受け売り気がする)。
具体的な流れとしては以下のような感じです。

1.DDD

どう組み込むかはまだはっきり見えていないのでTODOです…

2.SDD

あるストーリ(機能要求)があったとして、まずはそれを満たすStoryテストを記述する。
このテストはペンディングで構いません。
ペンディングで構わない理由は、GUIのテストは非常に複雑になってしまうこと、
機能要求レベルではUIが確定していないため「実現したい目的」を詰めていきたい、といったことが背景です。
このStoryテストが問題ない場合に、要件に落し込み設計を行います(BDDへ)。

3.BDD

機能要求レベルで合意が取られ、要件に落とし込む段階で、振る舞いの挙動を記述します。
振る舞いレベルで必要なモジュールを作成し、クラス化していきます(TDDへ)。
外部APIとして公開するような機能であれば、SDDと同様にペンディングレベルで確認が必要でしょう。

4.TDD

BDDで考えられたクラスやメソッドレベルの実装をTDDで設計を行いながら実装を行います。
このときテスタビリティのみではなく、デバッカビリティを考慮します。
つまり、TDDをやっていれば、必然的にテストしやすいコードとしにくいコードはわかると思いますので、
そこをインスペクションによって担保できるかを検討する必要があります。

xDDの連携によって得られる恩恵とは

ここでも書かれていますが、テストによってソフトの品質を保証する場合は、
何を重要視するかによって、必ずトレードオフが発生します。

但し、今回のように駆動単位でどの象限を保障し、品質を担保するかを行っている場合、
それぞれのフィールドにおいてお互いに補正することが可能になります。
これは非常に大きなメリットですね。

よく現場で言われる「品質」というバズワードは、こういった様々な目的に応じた
品質の属性を把握して議論できないため、内容が発散してしまっているように感じます。
実際に現場で活用する場合は、相手がどの部分を注視しているかを把握しながら、
交渉をしていきたいものです。

# 聖戦の系譜の外伝でトラキア776というSFCのゲームがあるんですが、
# それの聖戦士の書というのをなぜか連想しました。

参考

最後に@AfterClass

まぁ、なんだかんだいいつつ、すべて実行するのは難しいものですとか。
あと、xDDと命名された駆動開発の手法の多くは、
目的によって意識されやすいように命名されたものに過ぎないのかな、と思いました。

* 4象限をxDDで考えた場合は、厳密に分けられるわけではない。
* 常に特定の品質属性が求められるわけではなく、いつどこにフォーカスを当てるかによって変わる。

以上です。

広告

Posted in program | タグ: , , , , | Leave a Comment »

xDDについて考える2

Posted by hikaruworld : 2010 3月 27

このエントリは前回の続きです。

xDDの背景

では、なぜこのような多様な駆動開発が提唱されているのでしょうか。

ひとつの理由としては、いくらTDDのみ実践して問題ないことを保障しても、
前提部分で問題があった場合に、テスト自体が意味がなくなることが多々あるためだと思います。
「うまく設計できた、実装は終わった、テストは問題ない、但し顧客が求めている機能ではなかった」
というケースですね。

つまり、駆動する基準(求めているもの)がシステムを作る上で流動的に変化していくことを
把握し対応出来ていないため、アジャイル的な方法にあわせてより大きいレベルでの
駆動が求められているようになってきているのではないでしょうか。

「求めているもの」、つまり設計時に何を考慮しテスト時に何を保証したいかは
実践アジャイルテストに『テストの四象限』というものが定義されています(以下の図参照)。
この図はテストを整理するのにとても参考になります。

これはソフトウェアを構築するに当たって、どのような観点でテストを
行う必要があるかを4面性で分割したものです。

この4象限は、xDDのそれぞれの手法によって多角的に補足しているのではないかと思います。
逆説的に言えば、それぞれのxDD(駆動開発)はそれぞれのフィールドを
満たすための解決方法と考えることも出来るのではないでしょうか。

4象限によって保障されるもの

前述したように、この4象限を保証するために
それぞれ異なる手法が用いられます。

そうすることで、ことなるテスト品質の属性を担保することが出来るのではないかと、
考えるようになりました。
品質の属性はここがわかりやすいと思います。

では、具体的に領域別に用いられる手法や、保証される属性を考えていきたいと思います。

自動(単体テスト・コンポーネントテスト)

TDDによって設計、実装が行われる領域です。
TDDによって設計されたコードは、十分な設計や、利用者を考えたクラスの設計が行われるので、
柔軟性・保守性・試験性などが高いコードになると思います。

自動と手動(機能テストなど)

BDDによって設計される領域です。
基本的な振る舞い、前提条件の検証、イレギュラーケースの検証などが行われるため、
相互接続性、移植性、堅牢性などが注視されると思います。

手動(シナリオテストなど)

SDDによって設計、および評価が行われます。
ユーザニーズを満たしているかを中心とした受け入れテストなどに重点をおいてテストされるため、
主として、使用性が中心として設計されると思います。

ツール(性能テストなど)

その他のテストとは少し色合いが違いますが、
システム全体の構成などに関してはDDDの領域で設計・検証が行われると思います。
可用性、効率性、完全性、信頼性、などが検証事項の中心になるのではないかと思います。
※DDDに関しては自身なし。ただこのレベルじゃないと保証しても意味が無いかなと思います。

というわけで、妄想は次回に続きます。

以上です。

Posted in program | タグ: , , , , | Leave a Comment »

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によって生成されたテストコードから
品質保証用のユニットテストを生成することは構わないと思います。

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

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

次に続く。

Posted in program | タグ: , , , , | Leave a Comment »