JUnit for Androidについて

チュートリアルがここにあり、まずはここから、チュートリアル通りに打ち込んでみる。

http://developer.android.com/resources/tutorials/testing/activity_test.html


テスティングフレームワークについては、ここにあります。
http://developer.android.com/guide/topics/testing/testing_android.html

ポイントは、Instrumentation。何をしているかというと、アプリ(android.os.Contextより前？)とフレームワークの間に挟まって、
アプリ・フレームワーク間のイベントを仲介しているっぽい。
Instrumentationに対して、フレームワークからのイベントを送ってあげると、
アプリはあたかもフレームワークから来たイベントに見える。
また、Instrumentationのいる場所が場所なので、アプリの状態もみえるし、状態制御もできてしまう。

これが存在していることによって、Activityをテストするときも、単体試験自体を別スレッドとして、
Activityにテスト用のコードを記載せずに、テストできるようになるということ。
これは、Serviceであっても、当然同じ。

チュートリアルを一通り実施してから、フレームワークの説明を読むと、分かりやすいかなと。


ただし

これを使う場合には、まずはTest firstによる開発を勉強したほうがいいかな、と思います。

私はこんなので勉強しました。
こっちは、以前 流行ったXPの概要的な話で、単体試験自動化の話が一部。
��アフィです

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法
ピアソンエデュケーション
ケント ベック


Amazonアソシエイト by

こちらは、アジャイル全般。

アジャイルソフトウェア開発の奥義
ソフトバンククリエイティブ
ロバート・C・マーチン


Amazonアソシエイト by

ただ、これらの本には素晴らしいことがたくさん書かれていますが、会社で運用するのは難しいかなと・・・
そもそも、少人数(最大20人くらい？)で、メンバーのほとんどが、オブジェクト指向に精通していて、
設計も、コードもきっちりかけて、、、とかいう人が集まってないと、無理かなと思います。
だって、試験考えるのも、オブジェクト指向設計できないと考えられないし、
そもそもレベルの違う人とペアプログラミングなんて、できないよなぁ、、、

しかも、工数が見えづらい。エンジニアを「工数」という単位でしか見られない会社では、一生できないでしょう。

とはいえ、これらに書かれている考え方(非やり方)は、すごく面白く、大事と思います。
その考え方をどこまで適用・応用できるか、かな・・・＞自分