Jnarioで受け入れテスト

あんまり、日本語の情報がなかったのでメモ

Jnarioとは

実行可能な仕様書をつくるってふれこみのツールセット。

Eclipseと統合されているので使いやすい。Java屋さんにはいい。

http://jnario.org/

機能は

1. Cucumberライクなフィーチャ、シナリオのテスト作成
2. シナリオよりもうちっと詳細な仕様（Spec）のテスト作成
3. ドキュメントの自動生成

簡単にやってみます。

インストール

http://jnario.org/org/jnario/jnario/documentation/InstallingJnarioSpec.html

Eclipseマーケットでインストールできます。

JUnit4.10以上のJUnitプラグインがいるっぽい。STSにならそのまま入った。

Mavenから実行する必要ないなら、そのままでOK

フィーチャ作成

適当にproject作成してから、

新規作成->Jnario Feature 

作成された四則演算をする.featureファイル

クイックフィックスで、Jnarioライブラリをビルドパスに付け加えれば、エラーも消える。下が生成されたファイル

javaファイルの他、ドキュメントも生成されている。

（生成されていない場合は 設定ｰ>Jnarioでいろいろいじってみる。フォルダがない場合につくる、って項目にチェック入れれば多分いける。）

生成されていれば、.featureファイルをそのままJUnitで実行できる。

 フィーチャの記述

ほぼCucumberと同じ感じで.featureファイルに記述。
Xtend製のDSLなので、Givenなどのキーワードは強調表示とかしてくれる。キーワードの後には半角スペースをいれるらしい。

JUnitで実行

テスト記述 

Cucumberと違うのは、featureファイルにそのまま書きこむこと。また、Javaではなく、Javaを拡張したXtendで書く。

基本　仕様の中で""をつけると、argsでアクセスできる。アサーションは=>とか、　should be とか。コード部分は隠すこともできる。基本Javaなので、ライブラリは使えるし、SpringのContextConfigrationアノテーションとかもちょっと工夫すれば使える。

Suitesでフィーチャをカテゴリ別管理とかもできるし、結構いい。

http://jnario.org/org/jnario/suite/documentation/IntroducingJnarioSuitesSpec.html

設定面倒だけど、Mavenからも実行できるようにできるし、surefireでもレポート生成できる。つまり、jenkinsで回せる。アプリの本体にJnarioを入れるのもいいけど、専用のproject作った方がいいかな。まあ、開発プロセスの中での位置づけ次第か。

お客さんに納品する時は、生成されたHTMLを整形して、Office文書にするツールでもつくればいいんでないかな。設計書からソースを生成するより、ソースから設計書をつくる方が生産性高いと思っている。

はまったXtendとJavaとの違い

staticアクセス　クラス名::メソッド名　Math::random

キャスト　インスタンス名 as 型名　String s = object as String

Classインスタンスの取得　typeof(クラス名)　

顧客や業務設計者との作業同期 について

featureファイルを開発者と顧客とか、業務設計者が共有して手を入れると思う。怖いのは、シナリオが変更しているのに、テストが成功してしまうこと。多分、データ部分を変更したり、ANDキーワードで文章追加したら、検知可能と思うけど。。。

怖かったら、

 Background:
	Given フィーチャバージョン　"1.2"	
	val codeVersion =1.1
	args.first.toDouble should be codeVersion

 みたいな感じで、仕様とコードの同期とれるようにしておいて、仕様が変更されたら、版を変えるようにしておいたら何とかなるかな。ここらへん自動化したい気もするけど、仕様をコードに落とすのは、人間にしかできないことだと思うからしょうがない？

美しくないけど。。。

 プログラマの視点からは、業務設計者には、処理のHowではなく、What/シナリオ（例）やって欲しい。COBOLの時代は、詳細な処理設計に意味はあったと思うけど、コード書けない、言語の表現力を知らない人の処理設計にどれだけの意味があるのか。勿論、全てを否定するわけではないけど、結局コード書かないとちゃんとした処理手順なんて分かんないんでないかなあ。少なくとも自分はそう。

参考

Specification by Example: How Successful Teams Deliver the Right Software

実案件でやりたいな。もうちょっと、検証してチャレンジしてみるか。