ジャバで単体テストを書くにはどうしたらいいんや！と未だに悩んでる私ですこんばんわ。
仕事は仕様が固まらず&不明点が山盛りに対し、リリースが決まってる状態で辛いです。
JJUG CCC 2014 Fallにいったので思ったこととかをメモ。でも1日経ったせいでだいぶ忘れてる。
私がTDDできないのはどう考えてもお前らが悪い
http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd
概要に
- データベース(RDBMS)が関係するテストをどう扱うか
- モックをどのように使うか
とあったので、このあたりを聞きたかった。
DBのテストが遅い！モックしよう！と聞くけど、実際に遅かったらプロダクションで使えないよね、という事でDBを使ったユニットテストを実施しているらしい。
DBのテストデータはよくあるのはXLS形式だけど、バージョン管理が辛いので、XMLで以下のやり方にしているらしい。
確かにこっちのほうが良いかもしれない。マージする時もやりやすそう。
DBの検証には、操作前と操作後の状態を記録し、その差分と比較用のテストデータとつき合わせて比較するようにしているらしい。
変更箇所を全部書くのは辛いので、こちらのほうが良いかも。
実際にやるとなると、DBUnitならAssertionのDifferenceHandlerを使う感じになるかもしれない。
モックはSpringの例だったので、あまり参考にはならなかったけども、
- DIでモックに差し替えすると、次のテストにも影響が出る
- Contextを作り直すと時間がかかるので、テスト後に戻す処理を書いた
Spring Boot + Doma + AngularJSで作るERP（統合基幹業務システム）
http://www.slideshare.net/matsumana0101/20141115-jjug-ccc-2014-fall
Spring Bootが流行るんかなーと思って選んだセッション。
Spring Bootについての話はあまりなかった(多分別トラックでハンズオンがあったりしたため？)
Spring BootではSpring MVCによるAPIのみの提供として、AngularJSでAPIをリクエストして描画する形。
AngularJSはJSFよりサクサク動いたらしい。
ORMにDomaしかない理由については、S2Daoを使ってた流れもあり、Domaが一番しっくりきたとのこと。メンバーらの不満もなかったとか。
実例Javaトラブルシューティング！ 稼働中のシステムを立て直した半年間の軌跡
http://www.slideshare.net/shintanimoto/half-yeartroubleshooting
購入処理中のシステムエラー、1000秒を超えるレスポンスなどのトラブル、
酷いコード(多段ネスト、300,000行)にたいして、どのようにアプローチしたのか。
トリアージ(優先度の決定)、ログの視覚化(レスポンスタイム、スロークエリログ)による問題の原因の仮説・確認を淡々と行い大きな問題については対処したとのこと。
システムエラーについてはどの状態のときに起きたのか状態遷移を記録したり、エラー原因の件数が多いものから対処していったとか。
Javaだからこそできる、ビズリーチの攻めのDB変更
http://www.slideshare.net/jflute/jjug-bizreach-dbflute-2014
ちょうどDB周りで苦しんでるので、何かヒントがないかという感じで見に行った。
DBFluteを使ったDB変更時の影響の検知や、スキーマの一覧化(SchemaHTML)・変更履歴の管理(HistoryHTML)、Alterの整合性のチェック(AlterCheck)等について話されてた。
DBFluteにクラスファイルの生成を任せることで、変更箇所についてコンパイルエラーを起こさせる事が出来て、良い感じ。
結合を伴う場合、どうやってBeanにマッピングするんだろう。このあたりは自力かなぁ。
SchemaHTMLやSchemaHistoryはDDLさえあれば単体でも使えるようなので、試してみたい。
ここでもDBのテストデータの管理はツールを用いた
あと、デモで入力補完するときに省略記法(selectMemberStatusならselectMS)でやっていたのが気になった。
ElasticsearchとKibanaではじめる検索＆アナリティクス
https://speakerdeck.com/johtani/elasticsearchtokibanadehazimerujian-suo-anariteikusu
よく聞く組み合わせだったので、入門前に。
Elasticsearch社があることを初めて知った(ソフトウェアだけかと思っていた)
Elasticsearch、Kibana、LogStashはElasticsearch社が開発、OSSとして提供しているらしい。有償だが、MarvelというElasticsearchクラスタ管理ツールも作っているとか。
LogStashはElasticsearchと相性が良いFluentdという認識。
Elasticsearchの内部の仕組みの話がいくつかあった。
単語でインデックス化しているだとか、日本語はどう扱うか(N-gram, 形態素解析のいずれかをする必要がある)とか、大文字小文字は小文字に丸めてるとか。
ElasticsearchはREST APIでぽこぽこ叩けて良い感じなので、何かに使いたい。
1から10までJavaで書いた話
Perlで有名な人。
LLで色々開発していたが、ある日Javaで開発することになって、その開発の中で得た知見の話。
Java8 + lombokでだいぶ手軽にかける。型安全の点でLLより良い。
ただ、Javaのライブラリは全般的に軽量とは言えないんじゃないか、と感じていて、結果、自分で書くに至ったとか。
テストについても少し触れていて、
- モックは使わず、実際にembedded tomcatを立ち上げて、リクエストを投げる。起動は意外と早い。Jettyより遅い。
- 必要なテストデータは内部で使ってる作成処理を叩く(ユーザを作る時とか。こっちのカバレッジも取れて良いとか。)
など。
Java8時代に即したライブラリを書いて、Maven Central Repositoryに公開していける時期ではという話で〆
Webアプリケーションが主だったとのことだったので入力値のバリデーションをどうやってるか気になったので調べたら、
やはり、 tinyvalidator と言うものを作ってた。
作った理由としてはReadmeに書いてあるが、やはり軽量なのがほしかったとのこと。
おわり
今回は仕事で詰まってる部分が結構聞けて、自分の中でもいくつか整理ができた気がする。
色々思ったことがあったのでメモ。
DBのテストデータの扱いはテキストデータ形式にする
DBUnitとXLS形式を使ってると以下のような辛みがあって辛いので乗り換えたかった。
- 謎のExceptionがおきる。NullPointerExceptionとか。空白行を削除すると直る。
- nullを直感的に扱えない(ReplacementDataSetとか使わないといけない)
- VCSに入れても差分管理が機能しない
- テーブル名の長さに制限がある
オートフィルで手軽にテストデータを量産できるのはいいんだけど、性能試験目的以外ではそんなに要らない事に気づいた。
今後は実際にDBにデータを入れて、export/importする形にしたい。
軽量なライブラリ
実際に開発すると、依存ライブラリがごろごろくっついてきて辛い。
ロガーは仕方がない。仕方がないけど、ライブラリ間でロガーが違うだけでもちょっとだるい。
Guavaとか便利な汎用ライブラリは良いけど、それでもJava8対応してない(GuavaのOptionalを使ってる)とか、時代に追いつけてない。
ライブラリはSLF4Jとかロガーのアダプタのみに依存させて、実装は利用者に選ばせる形が良いなーと思ってる。
あまり標準のjava.util.loggingを使ったことがないのだけど、log4jとかcommons-loggingを作った人、使ってる人らがこっちを使わなかったのはなんでだろう。
log4jに慣れてるから使い続けてる感はあるのだけど。
クリエイティブな仕事をしたい
したい。
