LiveDataのUnitTest
ちょっとやっかいな部分もあったので、LiveDataのテストをどう書くのかまとめました。 build.gradle必要なものを追加します。LiveDataを使うので、もちろんArchitectureComponentを追加してます。 mockito-kotlin はmockitoをkotlinでいい感じに使うやつです。mockitoをそのまま使うとNull Safetyが影響したりするので、入れておくと良いと思います。 core-testing はLiveDataをテストする上で必要なものがあります。 同期処理テスト対象単純なViewModelをテストしてみます。この例だと、 fetchNameが呼ばれたらLiveDataに文字列を流してるだけです。 16行目: ここでは、Observerのmockを作成しています。mockitoを使って最後にverifyで値をチェックするためです。 17
Kotlin、MockitoによるRepositoryパターンのLocal Unit Testについて - Qiita
Kotlin、MockitoによるRepositoryパターンのLocal Unit TestについてAndroidKotlinMockito こんにちは、 Androidアプリエンジニアの大屋です 最近ようやくテストコードを書き始めたのでテストについてまとめていきたいと思います。 今回はRepositoryパターンのLocal Unit Testについてです。 現在、開発中のアプリですが、MVVM + Repositoryパターンのレイヤードアーキテクチャを採用していてRepositoryパターンの機構を単体テストするにはどうしたらいいのか気になったのでトライして見ました。 よろしくおねがいします💪💪💪 テスト実施用のサンプルアプリ あと、今回テストするのに簡単なサンプルアプリを用意しました。 アプリといってもSharedPreferencesに書き込み、読み込みをするだけのアプリ
既存コードをAndroid非依存なクラスに抽象化してユニットテストするための第一歩 - Qiita
これは Android その2 Advent Calendar の6日目の記事です。 はじめに ActivityやFragmentにビジネスロジックがありユニットテストしずらいコードに対して、Android非依存なクラスに抽象化することでテスタブルにする方法の紹介です。 今回はMVPアーキテクチャにすることでActivityに書いていたロジックをPresenterに抽象化してそこにテストを書いていきます。 注意点 実際に業務でアーキテクチャを選定する際は、プロダクトの規模、チームメンバーの技術力、事業の優先度などを考慮して上で決めたほうがいいので、必ずしもこのやり方がベストというわけではありません。 例えばプロダクトの立ち上げ時期はスピード優先の場合が多いので、この内容は適さない場合もあります。 やりたいこと（イメージ） 前提知識 MVPアーキテクチャとは Model-View-Prese
JUnit5とAndroidのテスト
Android Test Night #1 https://testnight.connpass.com/event/63753/ で発表した（する）スライドです。Read less
Androidテストハンズオン - Qiita
これは「DevFest Tokyo 2016 秋のコミュニティ祭り！」の発表資料です。 本ハンズオンの内容 DroidKaigi2016のAndroidアプリについてEspressoを使ってUI周りのテストコードを書いていきます。 Step 0：準備編 cloneする https://github.com/cattaka/droidkaigi2016 をcloneします。 Shellからcloneする場合 プロジェクトを開き、ビルドと実行できることを確認する Step 1：テスト用のライブラリを確認する 使用するテスト用のライブラリは次のものです。 JUnit いわずとしれたJava用のユニットテストライブラリです。 Mockito テスト時に各クラスをMock可するためのライブラリです。 具体的には通信処理のように、テスト中に本番の動きをされたら困るコンポーネントの動きを差し替えるために
Android の Parcelable なオブジェクトの保存と復元のユニットテスト - Qiita
Parcelable インターフェイスを実装したクラスについて、Bundle などへの保存とそこからの復元の機能をテストしたい。 ちょっと調べると、Parcel に直接 Parcelable なオブジェクトを保存して復元する方法を使ってユニットテストするという方法がいくつか見つかる。 Stuff I keep Forgetting How to Do: Unit Test Your Custom Parcelable Parcelableなクラスの単体テスト - _development, これらの方法だと、復元時に YourParcelableClass.CREATOR.createFromParcel(parcel) という感じでテスト対象のクラスの CREATOR を明示的に指定する必要がある。 もうちょっといい方法にしたいなー、と思って、いったん Bundle に追加した後、その
テストクラスをAndroid Instrumentation TestsとRobolectric Tests両方で走らせる - Islands in the byte stream
（追記: このハックはライブラリとして独立させました gfx/RobolectricInstrumentation · GitHub） Robolectricは便利ですが、Oracle JREとAndroid Runtimeの微妙な挙動の違い、特にAndroid Runtimeにバグの回避するようなコードのテストができないという問題があります。 ところでRobolectricを純粋にJVM用のAndroid Frameworkランタイムとみなすと、テストクラスをほとんどAndroid Instrumentation Testsと同じように書くことができます。 Robolectricのほうがテストの実行が速いので、開発中はRobolectricを使うほうが効率はいいのですが、微妙に挙動に違いがあるので実機でもテストは走らせたいところです。そこで同じテストクラスをAndroid Instrum
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Leveraging product flavors in Android Studio for hermetic testing
Leveraging product flavors in Android Studio for hermetic testing Posted by Jose Alcérreca, Developer Programs Engineer and Wojtek Kaliciński, Developer Advocate During our recent talk at Android Dev Summit, we discuss the state of testing on Android on the example of a simple Notes application that we created as part of our testing codelab. In one section of the talk, we discuss the problem of te
Robolectric 3.0でandroid.util.Logの出力を確認する方法 - Islands in the byte stream
テストケースクラスで以下の用に設定すると、 android.util.Log の結果がAndroid Studioのテストログに出力される。 static { System.setProperty("robolectric.logging", "stdout"); } テスト実行の際のVM optionsに -Drobolectric.logging=stdout を与えても同じだけど、異なるテスト設定を作るたびにこのオプションを設定するのは面倒だ。だから詳細なログが必要なテストケースでのみ有効にするのがいいと思う。コードに記録されるから情報共有もしやすいし。 なおrobolectricで実行すると BuildConfig.DEBUG が false になるので、ライブラリであればログの有効化は外から指定できるようにしたほうがいい。あるいはTimberのようなロガーを使うのも悪くない。 参
Mockito で @hide なメソッドをモックする - Qiita
public class SomeTest { private TestTarget mTarget; @Test public void something() { Something something = mock(Something.class); when(something.hogehoge()).thenReturn("mock"); mTarget.setSomething(something); mTarget.doit(); // 以後アサーション } } 何も難しいことはないですね。 でも、Something#hogehoge()が@hideだったらどうでしょう。 当然TestTarget内でもリフレクションで呼び出すことになりますが、Mockito でモックする場合はどうするのがよいでしょう。 public Utility { public static final
Android JUnit 4 形式のテストにする
InstrumentationTestRunner は JUnit 3 しかサポートしていませんが、Android Testing Support Library に含まれる AndroidJUnitRunner を使うと JUnit 4-compatible なテストを実行することができます。 （JUnit 3 と JUnit 4.10 までの JUnit 4 互換） Android 2.2 (API Level 8) 以上が必要です。 ▪️ Setup dependencies { androidTestCompile 'com.android.support.test:runner:0.3' // to use JUnit 4 rules androidTestCompile 'com.android.support.test:rules:0.3' } android { defau
Robolectric を 3.0 にアップデートするときにハマる箇所 - Qiita
公式のやることリスト 公式が Wiki にガイドを用意してくれています。基本的にはこのガイドに従ってアップデートしていきます。 足りない部分 しかしアプリケーションによっては足りない部分があり、テストがテストケースとは関係ない部分でバッタバッタと死んでいく事があります。 1. targetSdk が 22 で落ちる 現状 Robolectric 3.0 で対応しているのは 21 までです。targetSdkVersion を 22 にしていると、UnsupportedOperationExceptionでテストができません。 対応するには、@Configアノテーションでバージョンを指定します。 @Config(constants = BuildConfig.class, sdk = 21) public class SomeTest {} 2. MultiDex で落ちる Multidex
2015年7月時点でのJUnit4やEspressoを使ったAndroidアプリのテストについて - Qiita
以前「Androidのテスティングフレームワークを選定してみる」という記事を書いたのですが、最近久しぶりにEspressoを使ったテストコードを書こうと思って調べていたら、Espressoが2.0から2.2になっていたりして、いつのまにやらTesting Support Libraryが色々と更新されているようでした。 なので、メモがてら少しまとめてみました。 testing-support-libが分割された 以下の２つに分割されたようです。 com.android.support.test:runner com.android.support.test:rules Espresso 2.1のReleaseNotesに破壊的な変更点として記述されています。 Breaking Changes test runner artifact split into two and the name
エレクトロ・システム株式会社 公式 Google+
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Android CI: 2016 edition
僕がテスト書け書けおじさんになった経緯とその過程でやったこと - droidkaigi-2016 // Speaker Deck
Advanced Android Espresso
http://www.sarl-tokyo.com/wordpress/?p=516
開発を効率的に進めるられるまでの道程
