ひよっこ。

I want to…

Posts Tagged ‘BDD’

Mockito-Flexを利用してFlexのTDD/BDD環境を構築する(その2)

Posted by hikaruworld : 2011 2月 16

前回の続きになります。

Mockito-Flexの使い方

Java版のMockitoとの差異

基本的にはJava版のMockitoとほぼ同じですが、メソッドなど異なる部分もあります。
Java版のMockitoでは振る舞いのエミュレートの部分では、
when().thenを利用していましたが、mockito-flexの場合は、
given().willを利用する事になります。BDDMockito側を実装しているようですね。

ちょっとつらいのは、現在のmockitoでは複数の振る舞いの定義が出来ていないため、
以下のようなmockを書いても

given(hoge.piyo()).willReturn(“a”);
given(hoge.piyo()).willReturn(“b”);
given(hoge.piyo()).willReturn(“c”);

実行すると、以下のようになってしまいます。

trace(hoge.piyo()) // “a”
trace(hoge.piyo()) // “a”
trace(hoge.piyo()) // “a”

これは、Mockit-flex側でもIssuesとして、
#17 Multiple called given(something).willReturn(something) always returns first setted value
があがっていますが、まだ対応がはいっていないようです。
一応Answerを利用したやり方はあるようですので後述します。

Java版と同様な部分としては、DSL的な記述が可能なように
org.mockito.integrations以下にメソッド群が切り出されています。
Flex版ではグローバルメソッドとして定義されており、
Javaのようなstaticインポートが不要なところは言語的に楽ですね。

なお、これらのメソッドは実際はorg.mockito.Mockitoの
フィールドを呼び出すようになっています。
実際の挙動を確認する場合は、Mockitoの中身を確認すると良いかと思います。

Mockitoによる実装

ここからmockitoによって提供されている機能を確認していきます。
その際テスト対象のクラスが必要になりますので、
以下のクラスを対象にテストを行います。

public class Main
{
    public function Main()
    {
    }
    public function say(name:String):String
    {
        return "Hi " + name;
    }
    public function say(name:String):String
    {
        return "Hi " + name;
    }
    public function sayObj(obj:Object):String
    {
        return "obj is " + name;
    }
    public function check(data:Data):String
    {
        return data.userId;
    }
}
public class Data
{
	public var userId:int;
	public function Data()
	{
	}
}

なお、前回の方法でtargetに格納されている事とします。

Mock化

任意のクラスをMock化して振る舞いを設定する場合の方法です。

givenによる振る舞いの設定

given()を利用する場合は、以下のように記述します。

given(mock化するメソッドとその引数).willReturn(戻り値)

givenの引数にはmock化するメソッド[Mock]対象と、エミュレートしたい引数を設定します。
この引数はmockitoが提供するメソッドを利用して柔軟に設定する事が可能です。
willReturnはgivenによって与えられた条件時に返す値を定義します。
willReturn以外にも、will,willThrowがあります(詳しくは後述)。

引数のmock化

given時に引数をmock化するためのメソッドを見ていきます。

any()

any()は引数にどんな値を与えられても良い事を表します
(当然引数で定義される型の範囲内でですが)。
なお、any()はnull値を許容しますので、値がnullの場合でもmockとして処理されます

/**
 * anyのテストケースを検証_NULLでない場合
 */
[Test]
public function any_is_not_null():void
{
	given(target.say(any())).willReturn("piyo");
	
	var result:String = target.say("abc");
	
	assertThat(result, isA("piyo"));
}
/**
 * anyのテストケースを検証_NULLの場合
 */
[Test]
public function any_is_null():void
{
	given(target.say(any())).willReturn("piyo");

	// nullの場合でもwillReturnの値が返される
	// ちなみにundefでも問題なし
	var result:String = target.say(null);
	
	assertThat(result, isA("piyo"));
}

anyOf(Class)

anyOfも引数にどんな値を与えられても良い事を表します。
anyOfの引数には、対象の型を指定します。
例えばStringの場合は、anyOf(String)のように引数の型を指定します。

/**
 * anyOfのテストケースを検証_NULLでない場合
 */
[Test]
public function anyOf_is_not_null():void
{
	given(target.say(anyOf(String))).willReturn("piyo");

	var result:String = target.say("abc");

	assertThat(result, isA("piyo"));
}

ただし、前述のany()と異なりnull値を許容しません。mock化したメソッドに対して、
nullを引数に呼ばれた場合はArgumentErrorがthrowされます。

ArgumentError: obj cannot be null

havingPropertyOf

havingPropertyOf(property, value)は引数の持つプロパティの値が一致する場合に、
実行することが可能です。

[Test]
public function havingPropertyOf_test():void
{
        // 引数に渡されたプロパティuserIdが12の場合だけmock処理を行うように設定
	given(target.check(havingPropertyOf("userId", 12))).willReturn(22);

	var data:Data = new Data();
	data.userId = 12;
        // この場合にはwillReturnで指定した22が結果としてかえる。
	var result:int = target.check(data);

	verify().that(target.check(data));
	assertThat(result, isA(22));
}

TODO 継承周りとか調査

isItNaN

これはNaNつまり非数である場合にのみMock処理を行うために利用されます

[Test]
public function isItNaN_test():void
{
	given(target.sayObj(isItNaN())).willReturn("NaN value");

	var result:String = target.sayObj(Number.NaN);

	assertThat(result, isA("NaN value"));
}

notNull

そのまんまですね。値がnullでない場合のみMockのエミュレーションが実行されます。

[Test]
public function notNull_test():void
{
	given(target.say(notNull())).willReturn("Value is Null");

	var result:String = target.say("hoge");

	assertThat(result, isA("Value is Null"));
}

と、今回はこの辺で。
次回はverify周りに付いて書きます。

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

Mockito-Flexを利用してFlexのTDD/BDD環境を構築する(その1)

Posted by hikaruworld : 2011 2月 14

FlexでもユニットテストやMockライブラリが充実し、ずいぶんテストがしやすくなっています。
そこで、FlexでTDD/BDD環境の構築をしてみます。
なお、環境は以下のように構築しています

IDE FlashBuilderBurittoPreview
TestingFramework FlexUnit4 / Hamcrest-as / Mockito-Flex

Mockito-FlexはMock処理を簡単に行うためのフレームワークです。
内部的な実装はASMockに依存していますが、Mockitoを利用することで
ASMockのRecord->Replayの処理を省いて簡単にMockが作れるようになります(なるはず…)。

ライブラリの入手

必要な物を一通りダウンロードしてlibs以下においてパスを通します。

mockito-flex

今回の話題となるMockito-Flexです。
ここから現在の最新版1.4M5をダウンロードします。

FlexUnit4

FlashBuilder4にもFlexUnit4は同梱されているのですが、
ちょっと古いらしくRuleの実装がはいっていないバージョンです。
mockito-flexを利用する際、[Rule]があると楽できるため、ここから最新を落としておきます。
ちなみにバージョンは、FlexUnit4.1RC2でした。

Hamcrest-AS3

どうせなのでHamcrestのバージョンも最新にしておきましょう。
Hamcrest-as3はgitHubのここにあります。現時点での最新のバージョンは1.1.3になります。

テストうんぬん前にまずやるべき事

mockitoは最新版はAPIドキュメントなどもないので、ソースをダウンロードしておきます。
ソースはswcに紐つけておきましょう。
(Referenced Libraries -> mockito.XXX.swc -> 右クリックしてプロパティ -> ソース添付 -> 編集)
あと忘れずに、ASDocを作っておきます(以下はコマンドラインから)。

$ pwd
mockito-flex/mockito/src
$ asdoc -source-path ./main/flex/ -doc-sources ./main/flex/ -library-path ../libs/

まだドキュメントが十分そろっていないようですし、分からなくなったらASDocとソースを見るのが解決に一番の近道です。

テストのやりかた

さて、本題です。
ここにmockitoをFlexUnit4で動かすやり方が書いてありますので手順に従ってやっていきます。

基本的なやり方

mockitoをFlexUnit4上で利用するには3つの方法があるようです。

方法1:従来のケース

従来の方法?では、テストクラスへの[RunWith]を利用してmock化を行います。

/**
 * クラス宣言時にFlexUnit4の[RunWith]を利用してMockitoClassRunnerを指定
 */
[RunWith("org.mockito.integrations.flexunit4.MockitoClassRunner")]
public class MainTest
{
  /** Mock化対象のクラスを定義 */
  [Mock(type="com.wordpress.prepro.Main")]
  public var target:Main;
  
  // Testコード...
}

方法2:新しい方法(インスタンス化の制御を自信で行わない)

この方法を利用した場合、[Rule]の機能を利用してMockのインスタンス化が制御されます。
そのため、MockitoRuleを[Rule]メタタグを付けて初期化しておく必要があります。
ただし、インスタンス化の制御を[Rule]に依存するため、RunWithの設定を必要としません。

なお前述しましたが、Ruleは現在FBに同梱されているFlexUnitには含まれていません
ライブラリの部分の手順に従って、事前に最新版に置き換えておく必要があります。

/** [RunWith]は不要 */
public class MainTest
{
  /**
   * [Rule]でMockitoRuleをインスタンス化
   */
  [Rule]
  public var mockitoRule:IMethodRule = new MockitoRule();

  /**
   * Mock化対象クラスの宣言
   * 必ず***public***である必要がある。
   */
  [Mock(type="com.wordpress.prepro.Main")]
  public var mockie:Main;
  
  // Testコード...
}

なお、Mock化したいクラスにコンストラクタ引数が存在する場合は、以下のように設定します。
こうする事で、Mainクラスに引数1がコンストラクタ引数として渡されます。

/**
 * typeでMock化したいクラスを指定
 * argsListでコンストラクタに渡す値をもつフィールドを指定します
 */
[Mock(type="com.wordpress.prepro.Main", argsList="args")]
public var target:Main;
/**
 * Mock化するクラスに渡す引数を配列形式で定義します。
 */
public var args:Array = [1];

※ただし、この方法はドキュメント上には見つかりませんでした。
テストコードで見つけたので、今後どうなるかは不明です。

方法3:新しい方法2(インスタンス化の制御を自力で制御する)

方法2ではテスト実行時にmockオブジェクトが初期化※0されますが、
この方法を用いるとmock()メソッドを利用してmockオブジェクトのインスタンス化を制御します。

/**
 * Mock化対象クラスの宣言
 */
[Mock(type="com.wordpress.prepro.Main")]
public class MainTest
{
  /**
   * [Rule]でMockitoRuleをインスタンス化
   */
  [Rule]
  public var mockitoRule:IMethodRule = new MockitoRule();

  public var target:Main;
  
  // テストコード
  [Test]
  public function test():void
  {
    // mock()でmock化
    this.target = mock(Main);
  }
}

この方法のメリットは好きなときにmock化を制御できること、
また、その際にコンストラクタ引数を任意に指定できる事だと思います。

/**
 * Constructs mock object
 * @param clazz a class of the mock object
 * @param name a name used in various output
 * @param constructorArgs constructor arguments required to create mock instance
 * @return a mocked object
 */
function mock(clazz:Class, name:String=null, constructorArgs:Array=null):*;

とあるように、第一引数にMock化したいクラス名、第二引数にエイリアス?、
第三引数にコンストラクタ引数を指定する事が出来ます。

方法2のフィールド指定によるMock化では、コンストラクタ引数をプロパティとして、
定義しておく必要がありますが、方法3では、テストメソッド内でMockを組み立てながら、
引数を考える事が出来ます。

なお、不適切な引数の状態でMock化を指定した場合、
初期化時に以下のエラーが発生してしまいます。

ArgumentError: Incorrect number of constructor arguments supplied.

※0具体的には[Test]の実行時単位で初期化されます。

設定を間違った場合(タイポや、privateフィールドにしていたetc)などはmockオブジェクトの初期化に失敗するため、
nullアクセスのエラーが以下のようにメッセージ出力されます。
今のFlashBuilderだとカスタムメタデータまでは補完してくれないので、タイポに気をつけましょう….

TypeError: Error #1009: Cannot access a property or method of a null object reference.

何だか長くなってしまったので次に続きます。
次は、実際にmockやverifyを利用して[Test]を実行していきます。

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

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 »

easybを学ぶ0

Posted by hikaruworld : 2010 3月 3

@t_wadaさんがRSpecの入門とその1歩先へ という日記を書いていたので、
Rubyが使えない自分はJavaでeasybを使ったBDD導入の話を備忘録的に書いていこうと思います。

ちなみにマイコミの記事が大変参考になります。多謝。

個人的にはTDDだけじゃなくてBDD+TDDとかSDD+BDD+TDD的な流れになっていけば、
みんなで情報交換できて素敵なのにと思ってたりします。

eclipse上に環境構築(推奨)

easybってなんぞ?というお話はマイコミの記事なりWikipediaを読んでもらうとして、
とりあえずeclipse上に環境構築です。

easybはGroovyという、Java言語を関数的に使えるように拡張された言語で書かれているので、
eclipseさえインストールしておけば基本的にはGroovyとeasybのライブラリにパスを通すだけで、
簡単に動かすことが可能です(コマンドライン,Ant,etc…)。

…可能です、groovyのプラグインをインストールしておかないと、コード補完のないJava的なコードを
書く必要になるので、プラグインをインストールしておきましょう。
(いくら関数型的な記述が可能だからといって、import文を手動でとかはカンベンです)

Groovy-Eclipseのインストール

EclipseのGroovyプラグインGroovy-Eclipse をインストールします。
英語ですが、わかりやすい手順がこのURLにあります。
http://docs.codehaus.org/display/GROOVY/Install+Groovy-Eclipse+Plugin
なお、eclipse3.5か3.4.2以上にする必要があります。

3.4.1だとGroovyプラグインが動かないので注意が必要です。
(私はこれでハマりました)
eclipseのupdatesiteがあるので楽ちんです。
http://dist.springsource.org/release/GRECLIPSE/e3.5/

easybのインストール

ここからダウンロードしたeasyb-0.9.6.tar.gz を解凍してeclipseからパスを通すだけです。
楽チン。
以下の3つがありますが、Groovyプラグインをインストールしている場合は、groovy-1.6.4.jarは不要です。

  • commons-cli-1.2.jar
  • easyb-0.9.6.jar
  • groovy-1.6.4.jar

実行の設定

xDDなので、サクサク実行出来ることが大切です。
簡単に実行出来るように、以下のいずれかの設定を行っておきます。

  1. Runを使ってmainクラスの実行
  2. Ant経由で実行
  3. easybのeclipseプラグインを導入して実行

http://www.easyb.org/running.html

Runを使ってmainクラスの実行

eclipesのRunとして実行できると細かい単位で実行できて便利ですので設定しておきましょう。
0.サンプルプロジェクトとしてこんな感じに作りました。

1.「実行の構成」で設定を行います。

2.Groovyスクリプトを設定します。
「メイン・クラスの検索時にシステム・ライブラリーを組み込む」にチェックを入れて、
「org.easyb.BehaviorRunner」を設定します。

3.引数に実行対象のgroovyファイルを指定します。

以上で設定はOKです。
あとは必要に応じて実行しましょう。
ちなみに実行するとこんな感じでコンソールに出力されます。

Running hello story (HelloStory.groovy)

Scenarios run: 1, Failures: 0, Pending: 1, Time elapsed: 1.489 sec

1 behavior ran (including 1 pending behavior) with no failures

Ant経由で実行

一括実行はやはりAntで。後でHudsonでも設定したりするので、先に確認しておきましょう。
プロジェクトルートにこのような感じのbuild.xmlを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<project name="project" default="init" basedir=".">
	<target name="init">
		<!-- easybというタスクを登録 -->
		<taskdef name="easyb" classname="org.easyb.ant.BehaviorRunnerTask">
			<classpath id="build.classpath">
				<pathelement location="easyb-0.9.6/commons-cli-1.2.jar"/>
				<pathelement location="easyb-0.9.6/easyb-0.9.6.jar"/>
				<pathelement location="easyb-0.9.6/groovy-1.6.4.jar"/>
			</classpath>
		</taskdef>

		<!-- easybの実行 -->
		<easyb>
			<!-- easybで利用するクラスファイルへパスを通す -->
			<classpath>
				<path refid="build.classpath" />
			</classpath>
			<!-- レポートの出力形式を指定 -->
			<report location="target/story.txt" format="txtstory" />
			<report location="target/story.txt" format="html" />
			<!-- 振る舞いクラスを指定 -->
			<behaviors dir="src">
				<include name="**/*Story.groovy"/>
			</behaviors>
		</easyb>
	</target>
</project>
実行すると以下のようなコンソールログが出力されます。

Buildfile: /Users/***/***/workspace/Sample/build.xml
init:
[easyb] easyb is preparing to process 1 file(s)
[easyb] Running hello story (HelloStory.groovy)
[easyb] Scenarios run: 1, Failures: 0, Pending: 1, Time elapsed: 0.74 sec
[easyb] 1 behavior ran (including 1 pending behavior) with no failures
[easyb] easyb execution passed
BUILD SUCCESSFUL
Total time: 5 seconds

指定したレポート形式で実行結果が出力されます。
今回は割愛しますが、xml形式やprettyprintといった形式で出力することも可能です。

easybのeclipseプラグインを導入して実行

これが一番簡単です。

easyb のサイトにeclipseプラグインとして実行する方法がのっています。
この方法はupdatesiteでインストールできるのでお手軽です。
http://easyb.googlecode.com/svn/trunk/eclipse-plugins/org.easyb.eclipse.updatesite/

easybのeclipseプラグインをインストールすると、「新規」からeasybのファイルを生成出来るようになります。

「story」はStoryDSL、「指定」はBehavior DSLのテンプレートを生成してくれます。
実行に関しては作成したeasybファイルを右クリックして実行することで実行可能です。

実行結果はこんな感じになります。

Running A story (A.story)
Scenarios run: 1, Failures: 0, Pending: 0, Time elapsed: 1.0 sec

1 behavior ran with no failures

今日は環境構築まで。
次は、実際の実施手順に進みます。
以上です。

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