現在は「JUnit 実践入門」が題材で、今回は第4回です。
Twitter ハッシュタグ
#javareading
参加者は(自分のテリトリの) Java EE 層は少なめで、地図ソフトウェアや組み込みのお話が聞けて非常に刺激的です。話題によっては高度な話まで突っ込まれることがあり、理解できなくて悔しい思いをすることも多いですが。。
読書会のスタイル
参加者各々が順番に、時間を区切って音読していくのが基本になります。
そしてここが肝ですが、途中で疑問に思ったところやメンバに聞いてみたいことなどを、遠慮なくぽろりと聞きます。すると議論が始まります。これが非常に楽しい。自分が口を挟むもよし、色々な意見を傾聴するもよし、です。
これは私だけかもしれませんが、自分ひとりで本を読んでいると、特に難しい内容になると顕著ですが、「まああとでわかるだろう」と読み飛ばしてしまいがちです。そして、だいたいきちんと理解せずに読了してしまいます。この読書会のやり方では、疑問に思ったところを相談できます。疑問がその場で解決することもありますし、もちろん書籍の内容だけでは判断できないものは保留になることもあります。そういった場合でも、あとでちゃんと調べてみようと指針を立てたり、議論のうちに自分が何を理解していないのか整理できることがあります。非常によいスタイルだと思います。
実は社内でも、Java 仮想マシン仕様 の読書会をこのやり方で実施しています。この仕様書は自分にとって相当難解で、気楽に周りに相談できるという場は非常にありがたいです。
第4回 所感
※書籍の内容とは関係ない内容も含みます。
初めて知ったこと
- Java EE 7 の WebSocket はもう使われているシステムあり。LB や SSL アクセラレータをかましての動作実績もありそう。AP サーバは何使ってるか聞きそびれた。。Jetty あたりかなあ。次回聞いてみたい。
- 匿名 Inner クラスでメソッドを実装する際に、実装しようとするメソッドの外側にあるローカル変数は final つきでないと読めない。例えば boolean をチェックしたい場合は Boolean bool = false; などと宣言してしまうと、Inner クラス中で bool = true; などとできなくなるので、AtomicBoolean などを使って凌ぐしかない。
困り事と提案
- インターネット前提の Maven は使いづらい。
- たしかにその通りだと思う。プログラマがインターネットの利用を制限されている環境は少なくないかもしれない。ただ、Sonatype などを使って、社内のプライベートリポジトリを用意することで、毎回だれか(インターネット接続許可のある一部のひと)がライブラリをダウンロードするのに走り回る必要はなくなるんじゃないかと思う。
- システム依存や異常系のテストはどこまでやるか
- 線引きが難しい。ただ、参加者の方も言ってらしたけど、結合試験で実施した方が早いものなんかは割り切りも大事かなと。
情報共有
Arquillian による DB 接続を伴うユニットテスト
書籍中では DBUnit を利用したコードが紹介されています(接続コードだけでなく、DB 起動・停止、テスト実行における前処理・後処理、テストデータの設定含む)。
JBoss などの Java EE AP サーバを利用して開発をする際に、DB 接続部分と開発用 DB の起動・停止に関して簡略化する方法をご紹介します。
Arquillian という、JUnit と協調するテスティングフレームワークがあります。
これは Java EE AP サーバを実際に起動させることで、Java EE の本物のコンテナ(EJB や CDI など)をテスト中で使えるようにするものです。
これが ユニットテストにおける DB接続をどう簡略化させるかというと、JPA(Java EE 標準の ORM 仕様) + インメモリデータベースの組み合わせが鍵になります。
JBoss や GlassFish であれば 、内部にインメモリデータベース(H2 / Derby)を持っており、サーバの起動とともにこれら DB が立ち上がります。これで起動・停止は自動化されます。あとは通常のデータソース設定として DB 接続定義を記載しておけば、プロダクションコードと同様の仕組みで DB 接続ができます。Maven の設定次第では テスト用と開発用の DB を分けておく事もできます。
テストコード中の DB 接続コードについては、JPA では EntityManager というインタフェースを利用してエンティティの操作を行いますが、このインスタンスは @PersistenceContext とアノテーションを付与することでインジェクションされます(参考)。JPA は Java SE でも利用できますが、こういったインジェクションが可能なのは AP サーバのコンテナがあってこそのものです。
JPA を使いたくない場合でも、@Inject(CDI) や @Resource といったインジェクション用アノテーションを利用して、javax.sql.Datasource を取得できますので、すぐに DB 処理に関するコードを書き始められます。
前処理・後処理に関しては、通常通り @Before・@After を利用します。
前処理・後処理に関しては、通常通り @Before・@After を利用します。
調べる事
- Mockito の実装をちょっと読んでみたい。
0 件のコメント:
コメントを投稿