件のコメントandroidのServiceにandroid.os.Handlerを継承したクラスを実装して、定期的なバックグラウンド処理を実装することを考える。この定期処理は、バックグラウンドの処理結果によって、次開始するまでのsleep時間を変更するような実装にしたい。連携するWebサービスのAPIを実行したら電波が悪くて接続できなかった場合、またあるときはそのWebサーバが一時的にダウンしていた場合、前者はリトライの間隔を短く、後者は間隔を長くしたい。そのような挙動をテストしたいのだけど、問題が2つある。Handlerを使った処理でsleepしている間にJUnit側の処理が進む(または終わってしまう)ので、sleepからの復帰を待つ(同期する)必要があるsleepからの復帰をJUnit側はどうやって知るか1に関しては、java.util.concurrent.CountDownLatchを使うことで待たせることができる。非同期処理を待機するかどうかをHandlerではなく、AsyncTaskを継承したクラスの単体テストで、CountDownLatchの挙動を確認してみる。}}非同期処理の終りをJUnit側が知るには、onPostExecute()をJUnit側でOverrideする。そこで待機解除のメソッドを実行する。}runTestOnUiThread内で実行させてるのは、AsyncTaskを継承しているDummyTaskはUIスレッドで実行しないと正しく動作しないため。TimeUnit.SECONDS);のところで待機する。mSignal.countDown();の部分。mSignal.countDown()を1回呼べば待機が解除される。mSignal.await()の引数は、10秒以上待っても返ってこない場合は解除されるようにするもの。引数を設定しなければ、ひたすら待ち続けるので設定しておいた方がいいと思う。DummyTask戻り!おわりーというログが得られる。ちなみにmSignal.await()を設けず実行すると、非同期終了が表示される前にテストが終わってしまう。ここまで、問題の1つ目までは解決できたが、2つ目はどうするか...2つ目は冒頭の実装例で挙げたようにサービスで動いている挙動をテストしたいので、先ほどの単体テストのようにはいかず困った。いうやり方がベストかわからないけど、とりあえず苦肉の策ということで解決を図る。Handlerを実装しているクラスは、sleepからの復帰時にメッセージを飛ばすよう実装している。そのメッセージをJUnit側でも拾って、メッセージを拾ったタイミングでmSignal.countDown()を実行するというもの。}後はJUnitで該当のServiceを起動して、Handlerを実装部分を処理するよう促してやれば、JUnitのこのonReceiveにも飛んでくる。ちなみに、Serviceの話をしてたのにDummyReceiverにActivityを渡しているのは、ActivityからServiceを起動するようにしているため。これであとは、エラーになるよう仕向けたり、待機している時間の長さを測るように肉付けしてやればバックグラウンド処理の挙動をテストできると思う。今回はIntentFilterのメッセージを拾うようにできたけど、メッセージを飛ばさない実装の場合は、どうするか。人気の記事Eclipseの高速化メモEclipseが重いと一言に言っても、いろいろな工程での話があると思いますが、過去記事のなども含めてこの記事にピックアップしておきたいと思います。以下はWindows環境での話です。JavaでprivateなfieldやmethodにアクセスするJUnitでテストしてると、privateなフィールドにアクセスして、値を参照したりセットしたりしたくなるわけですが、よく使うのでメモしておきます。次のような対象のクラスがあるとします。...Eclipseで一通り基本的なGitを使ってみる備忘録的にまとめておきたいと思います。おかしな点があればご指摘いただければ幸いです。...Androidのlogcatを自動で保存させたいEclipseのlogcatビューは、いらないログはすぐ消してしまうので、さっきのログをもう一度見たいという時に、どこかに残ってないかなと思うことが時々あります。七輪で炭火焼きなどWindows7のデスクトップに自作ガジェットでWebページを表示させるHandlerによる定期処理の挙動をテストするにあたりJUnitから起動したService上でのApplicationのClassCastExceptio...ソーシャルアイコンの吹き出しCSSメモTumblrをWeb閲覧履歴ビューワーに。