かつてはAndroid依存のモジュールのテストはド遅いからPOJOとうまく分離してなるべくPOJOを通常のUnitテストで・・・とか思っていた時期があったんだけど、この分離ってやつが相当キツくて。ンカスプログラマだから。 つまりテスト書いてなかったんだけど、それはまだAndroid開発のノリがわかってなかったこともあったし、開発対象が画面の遷移周りがメインであまり小難しい処理がなかったんで、テストによるメリットよりデメリットが上回る可能性があったからで。 今はかなりわかってきたし、細かい実装もやっていかにゃあ、なんでもう一度テストについてよく調べてみたのよ。 そもそもAndroidモジュールが絡むテストが遅いのは Googleがandroid.jarにある全メソッドを"throw new RuntimeException("Stub!");"に変えている そのため、エミュレータなり実機なり
初めまして、リコーの沖田です。この度私もこの blog を書くことになりました。以後よろしくお願いいたします。 みなさんテストは好きですか？私も含めて私の同僚は皆テストが大好きなので、しばしばテストの議論で白熱しすぎてしまいます。今日はそのテストの中から Mock（モック） と Stub（スタブ） について書いてみたいと思います。 Test Double まずテストにおける Mock と Stub についてですが、これらは Test Double という概念の一部です。Double とは代役という意味で、テスト対象となるシステムが依存する外部のコンポーネントの代わりに、それらしく振舞ってくれるコンポーネントを代役として利用しようということです。 例えば Web アプリの Controller の単体テストがしたい場合に、Model の実装が完了するまでテストができないっていうのでは大変です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
