JJUG ナイト・セミナー 「Java エンジニアのためのJava(再)入門」
概要
「JUnitを使ったJavaのテスト入門」(19:00～19:50)
久保智
発表資料
http://www.slideshare.net/SatoshiKubo1/junitjava
今春に新しくエンジニアになられた方々は新人研修が終わり、
そろそろ現場に配属される頃かと思います。
そのような方々を対象にJavaのテスト方法の基本について解説します。
プログラムはただ作っただけで終わりではありません。
テストをして想定通りに動くことを確認する必要があります。
その第一歩としてJUnitを使った単体テストの方法について解説します。
「from old Java to modern Java ～職業プログラマに聞いて欲しいJava再入門」(20:00～21:00)
谷本心
発表資料
http://www.slideshare.net/shintanimoto/from-old-java-to-modern-java
エンジニアとしてすでにご活躍されている方々を対象に
Javaの新機能について解説します。
Javaが広く使われるようになってから10年以上経ちます。
その間に構文や機能について拡充が行われました。
新しい効率のよいライブラリの使用方法について解説します。
所感
なんとなくJava研修で言及される意味がわかった。
参加者の反応的に、言語仕様に技術者が追いついていない現状がある。
前半：JUnitってなんすかって人向け。
後半：Java歴が非常に短い人 or え？J2SE 1.4とJava SE5.0でそんな違うの？って人向け。
前半は半日で掴むJUnitの概要といった感じ。（新人研修みたいな）
アノテーションの確認から入るレベル。
チュートリアル部分は
「Eclipseで右クリックして出てきたメニューの中から。。。」
というレベルだったので、聞いていない。
後半は
「このバージョン以降は○○を使ってスマートにリファクタリングできるよ」
と言った流れ。
今、調べたらリフレクションがJ2SE 1.2からの仕様だったのでちとびっくり。
＃「1.4とかジェネリックもリフレクションもないんでしょ()」って思っていたから赤っ恥
いまだにJ2SE1.4で開発しているプロジェクトがあることにも驚いた。
＃インフラ系や金融系は簡単に移行できないからしょうがないだろうけど
登壇者も「1.4から7に移行するくらいなら完全新規のほうがマシ」とのこと。
あと、Oracle日本本社でやったのにNetBeansが公開処刑にあっていた
＃開発版はすこぶる評判がよくないらしい。
結論
InteliJでJava SE8 EA版を遊び倒すべしべし。
https://jdk8.java.net/download.html
＃JavaFXのデモzipだけでも結構楽しい。※要install JRE7, JavaFX 2.0
宣伝
ENdoSnipe
http://www.endosnipe.com/
OSSのJava解析ツール
＃レガシーコードやOSSのリバースエンジニアリングに使えそう。
TDDBC(Test Driven Deployment Boot Camp)
http://devtesting.jp/tddbc/
次回は7月に楽天タワーにて開催予定。
「JUnitを使ったJavaのテスト入門」
発表資料
http://www.slideshare.net/SatoshiKubo1/junitjava
JUnitを使わないと
プログラムがちゃんと動かないときどうするか？
Debugプリント。
デバッガでブレイクポイントとか。。。
上記方法の問題点
テスト方法を記録できない。
テスト実施手順を再現できない。
テスト結果を簡単に参照することができない。
テスト再現には人がもう一度操作する必要がある。
問題点の何が問題なのか？
一回テストをパスできればいいのではないか。
→そんなことはない。
例えばWindows OS開発。
Windows OSは短期間にアップデートやセキュリティパッチがリリースされる。
ソフトウェア開発一般論
一度リリースしたソフトウェアを更新しないで済むことはあまりほぼ無い。
近年のソフトウェアは大規模・複雑なので、変更の副作用がどこで発生するか予想できない。
機能追加・機能変更後にリグレッションテスト（回帰テスト）することが必須になっている。
リグレッションテスト（回帰テスト）
変更追加したとき、新たな不具合が起きていないか検証するテストのこと。
しかし、今までのテストを全て再度人力で行うとなると膨大な工数がかかる。＃3ヶ月とか
一ヶ月単位でリリース・アップデートを行うソフトウェア開発で上記のような人力テストでは対応できない。
なぜJUnitを使うのか
テストした内容を記録・テスト結果を再現するため。
いつでもテストを再実施できるようにしておくことでデグレを防止する。
テストは機械にやらせて人は開発に集中！
※JUnitが不向きなソフトウェア開発も当然存在する。
一度のリリース使い捨てにされるソフトウェア
数年単位でリリースするようなソフトウェア
JUnitの使いかた
・入手方法
IDEを利用しているならば大半がデフォルトで添付されている。
JUnitができること
特定のメソッドに対して、引数を指定し、期待された結果が得られるか検証できる。
＃このへんはWikiでも見たほうがわかりやすい。
EclipseでJUnitの使い方
＃いくらでも転がっている＆キャプチャ見ながらのほうがわかりやすいので割愛
HowTo本
JUnit実践入門
assertEqauls()を例にしたが、複数の値を検証できるaseertメソッドの使い方もフォローしている。
JUnitだけではなく、Jenkinsとの連携方法やAndroidアプリでの利用方法も記載されている。
実践テスト駆動開発
JUnitを開発手法のメインにした開発プロセス
＃テスト駆動開発（TDD: Test Driven Deployment）はxUnitを利用しなければいけないというわけではない。
テストと実装（品質検証と機能実現）を交互に行うことで、
品質を確保しながら実装を行える。
TDDとは
バグが半分以下になることで有名（らしい）
IBMとMSではTDD導入により、欠陥密度が（バグ/ステップ数）が格段に下がっている。
Visual Studio開発などでは実装時間は15-30%増加したが、
欠陥密度はTDDのほうが1/10になった実績がある。
質問時間
なぜ、assertEquals()を例に説明したの？
→JUnit初期のバージョンから存在する。直感的でわかりやすい。
＃JUnit4を使うならばassertThat()のほうがデファクトスタンダード。
Privateメソッドのテストの仕方は？
→リフレクションで強引にやれる。
→しかし、privateメソッドがそんなに重要ならば、Object志向的に別クラスにしたほうがいいのでは。
→リフレクションだと、メソッド名変わったらテスト失敗してしまう。
＃本来はメソッド名の変更により失敗するようなテストケースは
＃テスト仕様として除外（or変更に対応）されているはずなので、
＃テストで失敗するということは、テスト検討漏れ、
＃設計変更の影響範囲の過少評価の可能性がある。
＃よってテストするにこしたことがない。
＃コピペメソッドみたいなのが乱立するならば、privateメソッドで部品化しておいたほうがいい。
＃別クラス（Utilクラス？）にするという設計思想はよくわかりまてんでした。
from old Java to modern Java
発表テーマ：イマドキのJava ～文法編
Javaのバージョンアップによって進化する文法について。
発表資料
http://www.slideshare.net/shintanimoto/from-old-java-to-modern-java
Java 1.4→1.5
メンバ変数にthisは付けない。
＃thisを付けなくてもIDEが色分けしてくれる。
キャメルケースを用いること
＃スネークケースが悪いわけではない。Javaは伝統的にキャメルなのでリーダブル
＃エラーはエクセプションで伝播させること。
＃異常値をreturnするのはC-Like（関数言語的）な実装。
変数は使う直前に宣言する。スコープはできる限り小さく。
＃C言語に慣れていると関数の最初に宣言しがち
ハンガリアン記法はつかわない
＃int型にiFoo、char型にcBarとか。
引数に戻り値への参照を渡さない。（引数渡しで値を変更しない）
値を返却できたときは正常。異常値は例外で再現する。
＃1メソッド1機能の原則が守られているならば、戻り値で変更することが可能なはず。
＃どうしても複数変更したいならば、それはクラス化して一括管理（戻り値に）すべき。
Java1.5→Java SE1.6
ListなどのCollectionはジェネリックを利用して扱う型を明確に。
＃なんでも入るようなListではいけない。
for each（拡張For）構文を使ってイテレーションはシンプルにするのがリーダブル。
enumクラスを使いましょう。
1.5以降で定数インターフェース使っている場合。
enumクラスをstatic importする。
static importが1つ以上あったら*になるようにIDEを設定しておけばよい。
Native2asciiは面倒だから、IDEのプロパティファイル編集機能を使う。
Java SE6止まりで、Java SE7仕様あたりからあやしい人が多い。
Java SE6→Java SE7
finalyでcloseするのは古い定石。
tryでリソースを宣言すると、tryブロックから抜けるときにcloseされる。
ファイル読むだけならreadAllLines１行で終了することも出来る。
＃読込行ごとに処理を変更する場合は別。
hashCodeが自動生成できるようになった。
before
自前で実装すると死ぬからだいたいIDEで自動生成
after
Java SE7はObject.hash一行で終了
Collectionの宣言で右辺の型名は省略する。
ex: List fooList = new List< >
オブジェクトハッシュが追加されたのは大きいですよー。
Java SE7→Java SE8
いよいよ導入されるProject Lambda
Before
ListをSortする場合、Comparatorを使う。
after
Listのstream処理を開始。
stream().filter(抽出条件).sorted(整列条件).collect(結果収集)
これでリスト検索＆サーチが完了する。
filterで絞り込んで、sortedでソートして、collectで取り出す。
ファンクションインターフェース。ひとつだけ実装が必要なインターフェース。
List処理や、アクションイベントなどの
単一メソッドの無名クラスはLambda式で解決。
stream()を使うほうが性能的にも俄然早い＃そしてスレッドセーフ（！）
