fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「『JUnit実践入門』写経・実践会 in 横浜 #5」に参加しました

2013/4/14(日) 「『JUnit実践入門』写経・実践会 in 横浜 #5」に参加してきました。

DoorKeeper
http://connpass.com/event/1962/

Togetter
http://togetter.com/li/465948

以下の書籍をターゲットとした写経会なのです。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
(2012/11/21)
渡辺 修司

商品詳細を見る


場所は横浜のタネマキさんです。
参加者は17名くらいでしょうか。これまでで参加者の人数が一番多かったようです。

今日は「第17章 振舞駆動開発」が対象でした。
いちおう一通り読んで、サンプルを動かして、写経は途中までしてから参加しました。
以下、個人的メモ。

『JUnit実践入門』写経・実践会 in 横浜 #5 from shinyaa31

■「17.1節　受け入れテストとは？」に関するディスカッション
■ユーザが受入テストやってくれている人は？　→　参加者の半分くらい。
・参加者の大半がウォーターフォールかも。
・要件定義に対するテストが受入テストである。
・エンタープライズのメーカー系だと、受け入れテストをやるのは品質保証部門(QA)だったりする。
　（メーカーだと、ユーザはコンシューマなので、ユーザが受け入れテストできないので）
　→ プロダクトに責任をもっているQAとかシナリオを書き、仕様書に沿って操作をして受入テストをする。
・発注の時に仕様を曖昧にしておいたほうがいい、というのはある。

■BDDについて
・BDDには「ユーザー視点」と「開発者視点」の2パターンがあるのでは。
　→　それを「BDD」として１つに纏めるのに違和感がある。

■TDDとBDDの違いについて
・明確に分類はあるような気がするが、境界線がふわっとしているという感覚。
・BDDを仕事で使ってる人は？　→　参加者でいなかった。
・BDDは、フレームワークというより視点の違いでは。
・プロセスとしてのBDDと、フレームワークとしてのBDDがある。
・プロダクトコードのクラスとテストコードのクラスを１対１に対応させると、変更に脆くなる。
　→　BDDはそこに自由度を持たせ、外部仕様の振る舞いは動かさないけど、内部仕様は変えても大丈夫、とする。
・JunitだけでもBDDできるんじゃね？
　→　JunitだけでもBDDできるかもだけど、Cucumberの方がBDDやるんだったら書きやすいだけでは。
・アジャイルサムライ横浜道場でCucumberハンズオンをやった時のスライドに、ユニットテストとの違いが書いてある。



・上の資料では、BDDには以下の書籍に書いてある前提知識がある方が良い、と言っている。
①継続的デリバリー

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
(2012/03/14)
David Farley、Jez Humble 他

商品詳細を見る

②エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
(2011/04/09)
エリック・エヴァンス

商品詳細を見る


・ウォーターフォールのV字モデルだと、受入テストの反対側に要件定義や基本設計があるが、そこでBDDを書くのが理想。
　→　でも難しいよね。

■「17.2節 振舞駆動開発とは？」に関するディスカッション
■Cucumberはシナリオを日本語で書いて、それをテストコードに結びつける。
・可変部分がある日本語で書いて、それをテストコードに結びつける。

■誰が嬉しいかでTDDとBDDを区別できるのでは。
・TDDは開発者で、BDDはお客さん。
・BDDはTDDの先にある。
・BDDはユーザ視点が入ってくるのでは。

■Cucumber-JunitとRSpec
・JunitはJava。それに対しRSpecはrubyというよりDSLに近い。
・メタプログラミングを使うことによって、DSLによって、テストの中でテスト対象の振る舞いを駆動していくことに気づいた。
・CucumberはRSpecが起源。

■アジャイル開発でユーザーストーリーをどう判断するのか？
→　受入テストを自動実行可能にすればいいのでは。

・受入テストの自動化と単体テストの自動化は補完しあう。どちらがいらなくなるわけではない。
・アジャイル開発だとDoneの定義としてフィーチャーテストを書けば、駆動してると言えるのでは。

■GOOS本の「外側のフィードバックループ」とBDDの関係について
・GOOS本では、外側のフィードバックループとして「失敗する受け入れテストを書け」と言っている。
　→　受け入れテストでエンドツーエンドのテストまでやれ。
・GOOS本では、外側のループもTDDの一部といっているような気がした。
・ただ、あれはモックでインタフェースを繋ぐことに焦点があるので、エンドツーエンドとは言い切れない部分もある。
・GOOS本は開発者視点だし。

■Cucumberはシナリオさえあれば、コードがなくてもテストできる。
・ただ、テストを実装してないのにテストを実行すると緑になってしまうのがダメなところ。

■BDDだと、お客さん側に厳密さが求めれるのでは。
・以前は「こんな感じでやっといて」とお客さんがベンダに伝えるだけで開発を進めることができたが、BDDだとテストを明確に定義しないといけない。
→ お客さんの負担が上がる？

■LTタイム　其の壱

■LT No.1　@ageさん：「社内勉強会のSpock紹介資料」
@aeg さんの同僚の @yamkazu さんがSpcokに関していろいろやっていて、社内勉強会をやった。
https://github.com/yamkazu

今日のLT資料は後日公開予定とのこと。

■「17.3節　cucumber-junitによる振舞駆動開発」
　各自BDDに関する実践タイム（15時～18時）

各自、好きなBDDフレームワークを使って写経なりペアプロなり、実践する時間が3時間ほど。
私は書籍の17章の写経が残っていたところを実装し、ポーカーのツーペアのテストを追加で実装するトコまでやりました。
あとは時々、休憩にジョジョを読みつつ、ひとまず7巻まで読んだ。



ちなみにcucumber-junitのjarの最新版だと、featureファイルの「ならば」という文字でうまくいかないようです。




とりあえずjarのバージョンを書籍と同じ1.08に合わせれば大丈夫だとか。

■LTタイム　其の弐（18時～）

■LT No.2 @ryu22eさん： PythonのBDDフレームワークbehaveについて
・Git: https://github.com/ryu22e/junitbook-behave
・behaveの日本語訳を現在されているそうです



■LT No.3 @shinyaa31さん： BDDフレームワークJnarioについて






■LT No.4 ‏@grimroseさん：　Groovy, Spock, Gradleを使ったBDD



■まとめ
■cucumber-junitを使ってみた感想 by cucumber-junitチーム
・cucumber-junitをオススメできるかをcucumber-junitチーム8人に聞いてみた。
　→ Yesは、8人中0人。。。 orz
・なんか、Junitでも良くね・・・？
・cucumber-junitのjarのバージョンの違いのせいで、写経でパスや日本語でハマることがあった。
・テスト未実装で実行させると、デフォルトで緑になるのが危険すぎ。

■次回の写経会は5/25の予定。

★感想：
cucumberは前から興味あったんですが、今回初めて触りました。
日本語でシナリオを書いてテストに繋げていくトコが斬新です。
でも、日本語で書けるからといってこのシナリオファイルをお客さん自身で書けるか、というと難しいと思います。
要件を決めきれない、仕様に落とせないお客さんが多いと思うので、現実はやはりエンジニアが書く事になるのかなぁ。
ただ今日の話にも出ましたが、cucumber使ってシナリオ起こしてテスト全部やろう！という思想に無理に持っていく必要はないでしょうね。
Junitの単体テストと補完し合うように仕込んでみたり、デプロイ後のスモークテストとして一部のシナリオテストをJenkinsに仕掛けるためにcucumberでテスト書く、というくらいが最初はいいのでは。
Junitよりもシナリオベースのテストが書きやすいのがCucumber、というくらい認識です。
まだ今日1日写経しただけなのでなんとも言えませんが。。。

あとは、Seleniumもちょと触ってみたいと思っている。
次回がCIの章あたりで、その次がWebのテストあたりやるらしいので、その時にやるくらいかな。

最後に主催者の @shinyaa31さん、参加者の皆さんありがとうございました。

-->