FitNesseなどによるSpecification By Example

はじめに

LEANやAgile、BDDやATDDなどとあわせて、Specification by Exampleという、包括的な考え方が広まってきました。

これは、例によって振る舞い（仕様）を定めていく、という形のアプローチになりますが、そのときによく使われるツールが着想として面白い。

仕様としての例をWikiにより管理し、実装対象の例えばAPIに対してインプット、アウトプットを定義する。そしてそれを受け入れ試験の1つとして活用する。

これは、自然言語で例を与えながら仕様を明確にしていくことと、Wiki形式で表現することで理解しやすい形式にすること、開発物のインタフェースの検証のテストとして受け入れテストのインプット・アウトプットの検証にそのままWikiの記述が使われるところが有用です。

つまるとこ、仕様がそのまま受け入れ基準になるため、仕様と実際のインターフェースの振る舞いの差分を小さくメンテナンスし続けることができる方法を提供します。

ただ、なれるまでは開発速度が遅くなるかもしれませんが。。

このRubyでFitNesseを使うライブラリとして以下がありました。
FitNEsse: http://fitnesse.org
RubySlim: https://github.com/unclebob/RubySlim

FitNesseの例は以下になります。
– http://fitnesse.org/FitNesse.UserGuide.TwoMinuteExample
あわせて興味あるひとはFitNesseのアーキテクチャをみてみると良いです。

例

例えば、以下のnumerator、denominatorがインプットの例、quotient?が検証する値となります。その実際のAPIへの受け渡しはここでは隠蔽しておきますが、このTableの記述がそのまま仕様の例にも、受け入れテストにもなります。

|eg.Division|
|numerator|denominator|quotient?|
|10 |2 |5 |
|12.6 |3 |4.2 |
|100 |4 |33 |

なお、この形式に似ているものとしてCucumerやTurnipのtable specが存在します。
※以下はTurnipの例
https://github.com/jnicklas/turnip#table-steps

Scenario: This is a feature with a table
Given there are the following monsters:
| Name | Hitpoints |
| Blaaarg | 23 |
| Moorg | 12 |
Then "Blaaarg" should have 23 hitpoints
And "Moorg" should have 12 hit points

このように記述してシナリオのインプット、アウトプットになるのですが、これはおそらくWikiもしくはGithubで管理するとSpecification by Exampleとしての例として使えると思います。

考え方はおそらく同じで、重要なのは WkiやMarkdownに記述された内容がそのまま仕様にも、そのAPIなどに対する受け入れ試験にもなることだと思います。それにより、メンテナンスする価値のあるコミュニケーションツールとしての仕様、ドキュメント、具体例の役割となる点かと思います。

Agile Testingなどの分野で、少ないメンテナンスコストで、いくつかのチームをまたぐ開発において、このSpecifiction by Exampleはひとつの流れになっていますね。

実際に内部でどれだけ有効になるかは不明なのですが、どうせ仕様として残すなら、それをそのまま検証のための受け入れ試験のインプットにする形を模索するのも楽しいかも、と思いました。

なお、国内ではFitNesseをどれだけ利用しているのかはわかりません、、、
※海外のAgileなチームでは、ほぼデファクトスタンダードなツールのようですが。多くの書籍でみますし。

キーワード駆動テストと呼ばれる、変更に比較的強いテストの記述形式としてこのようなTable Specを使ったものがあげられます。Turnipを使ってシナリオを記述・試験を回すことができう環境が作れればキーワード駆動テストの土台になりそうですね。