Setup Android Studio 1.2 で Robolectric3.0を準備する. build.gradle モジュールのbuild.gradleに下記ライブラリを追加. // UnitTest用. testCompile 'junit:junit:4.12' testCompile "org.mockito:mockito-core:1.9.5" // Robolectric用 testCompile 'org.robolectric:robolectric:3.0-rc2' Android gradle 1.1以降, AndroidStudioからのUnitTest実行がサポートされた. http://tools.android.com/tech-docs/unit-testing-support build.gradleの全容は下記. app/build.gradle B
AndroidのテストをRobolectric, Mockito, PowerMockを使用して行うように環境を整えます。【Android】Robolectirc & Mockito & PowerMockでテストする Posted in Android By Yohei On 2014/05/14 今回はAndroidのテストにPowerMockを仲間にいれようという話です。 簡単な説明 Robolectric Androidのテストが高速かつJunit4を使えるのですごく便利になります。導入はこちらから。 Mockitoではfinalクラスのモックオブジェクト作成や、static finalなフィールド変数の変更ができません。PowerMockを使うとそれが出来てしまう強力なモックライブラリーなります。 導入方法 Robolectric, Mockitoについては下記を参照して下さい。
概要 Espresso 2.0 が Android support library の一部としてリリースされた - ひだまりソケットは壊れない espressoの他にtesting-support-libというのがsupport packageに増えたそうです。 で、testing-support-libを使うと手軽にJUnit4をAndroidアプリケーションに導入できます。 手順 1. Android Support Repositoryを最新にする Android SDK ManagerでAndroid Support Repositoryを最新にします。 2. build.gradleに設定 build.gradleにtesting-support-libの設定を書く。差分は以下の通り。 android { defaultConfig { testInstrumentationRu
27. DroidKaigi 2015/04/25 @cattaka_net SharedPreferencesの差し替え プロダクションコード public class SharedPreferencesFactory { static SharedPreferencesFactory INSTANCE = new SharedPreferencesFactory(); public static SharedPreferencesFactory getInstance() { return INSTANCE; } public SharedPreferences newInstance(Context context, String name) { return context.getSharedPreferences(name, Context.MODE_PRIVATE); } }
もう先週ですが、表題のタイトルで「Consumer Service Engineer MeetUp Vol.1 ~iOS編~」という会でお話しさせていただきました。 このようなタイトルの発表にした理由についてですが、はてなとしてお話しするということで、ちょっと硬派な方に振ってみました。結果としては良いバランスだったのではないでしょうか。 発表資料を掲載します。 また以下に発表の概略を書いておきました。ご参考ください。 前提 このMeet Upの主旨が「コンシューマ向けのWEBサービス(アプリ)の企画・開発・運営をしている会社によるエンジニア向けの講演、パネルディスカッション、懇親会を含めたMeetUpです!」となっていましたので、それではWebサービスとアプリを繋ぐWeb APIについて、それを利用するiOSアプリについて考えます。Web APIというのは古くて新しい話題で、いまや専らJS
今回エンジニアブログを担当する、藤澤です。 早いものでエンジニアブログが始まって一ヶ月半が経ちました。多くの方に見ていただきありがとうございます! 見て頂いてる方からこのようなリクエストをいただきました。 「実際のコードによるiOS のテスト自動化(OCUnit+α)をお願いしたし!」 正直これを聞いて初めて OCUnit の存在を知ったわけですが、赤を緑にする作業に取り憑かれた身として Cocos2d-x と OCUnit (※) でどこまで TDD な開発ができるか試してみました。 ※ 中身は SenTestingToolkit というライブラリのようなので検索ワードにはこちらがよいかもです。 準備編 Cocos2d-x のプロジェクトで OCUnit を使うための準備ですが、以下の手順でいけました。 1.Cocos2d-x のプロジェクト作成 まずは普通にプロジェクトを作成します。こ
NAME Test::More - yet another framework for writing test scripts SYNOPSIS use Test::More tests => 23; # or use Test::More skip_all => $reason; # or use Test::More; # see done_testing() require_ok( 'Some::Module' ); # Various ways to say "ok" ok($got eq $expected, $test_name); is ($got, $expected, $test_name); isnt($got, $expected, $test_name); # Rather than print STDERR "# here's what went wrong\n
メタデータからテスト件数を取得する 前回はテストファイルやテストデータの数からテストプランを計算するモジュールを紹介しました。今回はその続きとして、テストファイルのメタデータからテストの数を求めるモジュールを紹介していきましょう。これらのモジュールの多くは1994年にケント・ベック(Kent Beck)氏がSmalltalk向けに書いたSUnitを祖先にもつ、いわゆるxUnit系のフレームワークに属するものですが、Perlにはそれ以前からTest Anything Protocolを使った独自のテスト手法が存在していたため、Javaなどで使われている同種のフレームワークとはやや毛色の違う部分もあります。一般的にはクラスをひとつ書くたびに対応するユニットテスト用のクラスを書くのがよいように言われていますが、ここではもっとゆるく、テストを自動的に検出してくれるだけでなく、テストの事前事後になん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く