読書会(JUnit実践入門)第5回議事録

============================================
Java読書会BOF 「JUnit実践入門」を読む会第5回
============================================

.. csv-table:: 開催概要

"日時", "2013年7月13日 10:00 - 17:00"
"場所", "川崎市教育文化会館　第３会議室"
"出席者(敬称略)", "遠藤、門脇、高久、高橋(徹)、高橋(智)、田辺、中澤、中島、根本、松永、村山、山田、吉本(書記)"

議事
====

13 Androidのテスト
------------------

13.1 GUIアプリケーションの設計
------------------------------

* 最近の若いエンジニアはコマンドを知らない。

* Windowsしか使ったことがないから？

* ビューがモデルを参照していいのか？

* ビューがデータ型を判断するのにモデルを見ないとならない。

* これが本来のMVCじゃないの？

* WebアプリケーションのMVCの場合、コントローラが肥大しやすい。

* MMVCの考え方もある。

* MVPというものもある。

* モデルとはどこまでの範囲を指すのか？

* データだけじゃないはず。

* ビジネスロジックの行き場所はいろいろある。別レイヤにしたり。

* MacのGUIもシングルスレッドなのか？

* Macもシングルスレッドのはず。

* Windowsと変わらない。

* OpenGLなどを使えばマルチスレッドに出来るかもしれない。

* GUIのマルチスレッドは止めておいた方がいい。

* GUIの設計が破綻する。

* WindowsもMacもイベントにはキューを使っているので、そもそもマルチスレッドは無理だろう。

13.2 MVCパターンによるAndroidアプリケーションの作成
---------------------------------------------------

13.3 モデルのテスト
-------------------

* リスト13.7の15行目　3項演算子のtrue時の処理とfalse時の処理が逆。

* 2刷では修正済

* モデルを独立したプロジェクトで作るというのは、どのようにやっているのか？

* モデルが増えるとコストが高くなる。

* 増える前に環境を作るしかない。

* そうしないとCI（継続的インテグレーション）ができない。

* 失敗したプロジェクトと成功したプロジェクトがある。

* 失敗したプロジェクトがあることが分からない。

* 失敗したプロジェクトは作ったモデルをコントロールできなくなったため。

* モデルのテストをしなかったのがよくなかっただけでは？

* モデルが他のプロジェクトで使えるのか？というのは、もう１歩先の問題。

* モデルを独立させるメリットは、モデルからビューを参照出来ないようにすること。

* モデルにAndroidのGUIに関連するものが入ってきたらどうするのか？

* ここでのMVCでは「入れるな」とういうこと。

* POJOで作るということか。

* runtimeに依存しないもので作る。

* リスト13.10　httpClientをパッケージプライベートでnullをセットしているのは、テストを意識しているのだろう。

* リスト13.11　下２つのモックのreturn値がJSONの形式に合っていない。

* 文字列はダブルクォーテーションで囲まないとならない。

* シングルクォーテーションも使えない。

* resultとsuccessを両方囲う必要がある。

13.4 ビューとコントローラのテスト
---------------------------------

* リスト13.14　assertEqualsの引数の順番が逆。

* 「気をつけろ」と書いていながら本人がやっちゃった。

* Androidエミュレータは遅くて使いものにならない。

* 遅いのはわかっているが、使える部分では１つの選択肢としたい。

* CIに組み込む際、実行速度が要求されない使い方は出来る。

* 朝来て結果が出ているくらいでもいいものはある。

* 一部が出来ないからといって全てを否定するのはどうかと思う。

* 利用出来る部分だけでも使いたい。

* リスト13.15　sendKeysとassertEqualsで、文字が大文字と小文字で違うがいいのか？

* sendKeysでは、文字列ではなく、スペース区切りでキー入力された文字として送っているのでは？

* 小文字はどうすればいいのか？

* キー入力として文字を送るだけなので、小文字が送られると思う。

* 逆に、大文字の方が難しい。

13.5 GUIアプリケーションのテストにおける注意点
----------------------------------------------

* なぜいきなりSeleniumが出てくるのか。

* 機能テスト繋がりだからだろう。

* そもそもSeleniumはAndroidで動くのか？

* ブラウザの種類に依存するので、分からない。

* ChromeにはSeleniumは対応しているが・・・。

14 コードカバレッジ
-------------------

14.1 コードカバレッジとは？
---------------------------

* 3項演算子の場合、カバレッジはどうなるのか？

* 1文だけど、C1になるのか？

* C0だろう

* 3項演算子だとバイナリベースでカバレッジを取らないと意味が無い。

* カバレッジが100%になったからといって、品質が上がるとは思えない。

* ソースの書き方によって、どうとでもなる。

* カバレッジの数字が上がっても、品質は逆に悪くなることもある。

* catch文でExceptionだけを記述するとカバレッジ率は上がるが、テストしない例外が出てくる。

* C2カバレッジを測定出来るツールはほとんど無いとされているが？

* C++ではある。テクマトリクスのツールが有名。

* EclEMMAではやってそう。

* あることはあるが・・・。

* カバレッジはあくまでもソース上の話で、仕様上のカバレッジではない。

* ソースから抜けているものは分からない。

14.2 カバレッジツールの利用
---------------------------

14.3 EclEMMAによるカバレッジ測定
--------------------------------

* メソッドカウンタと型カウンタの違いは？

* 型カウンタは、少なくとも１つのメソッドが実行されればカウントされる。

* その型（クラス）が使われたかどうかだけ。

* メソッド単位かクラス単位かの違いだと思われる。

14.4 カバレッジに関するよくある疑問
-----------------------------------

* カバレッジが80～90%というのは本当？

* 数字的には妥当。

* 普通は100%を目指さないの？

* 数字に正解はないので、説明するのは難しい。

* 100%にすることを目的にするのは本末転倒。

* 100%という数字に意味は無い。

15 継続的テスト
---------------

15.1 継続的テスト
-----------------

15.2 Mavenによるビルドプロセスの自動化
--------------------------------------

* JaCoCoは、バイナリに手を入れるタイプのツールか？

* そうだと思う。

* Androidでは動かない？

* だと思う。

15.3 バージョン管理システムによる継続的テストの運用
---------------------------------------------------

.. note:: 次回は、p.296「バージョン管理システムへのコミット」から。

[ 戻る ]