Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
![物理サーバを選定する際のポイント – Eureka Engineering – Medium](https://cdn-ak-scissors.b.st-hatena.com/image/square/96c17240e5e2d585a7b88afbfdb589268b9535b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-images-1.medium.com%2Fmax%2F1200%2F1%2A4nQvYibd3aHYOp1xrvmfMQ.png)
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
package sample.assertj; import org.junit.Test; import static org.assertj.core.api.Assertions.*; public class MainTest { @Test public void test() { assertThat("hoge").isEqualTo("Hoge"); } } org.junit.ComparisonFailure: expected:<"[H]oge"> but was:<"[h]oge"> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstru
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
先日、RxAnimationというAndroidのアニメーションのイベントをObservableでラッピングするライブラリを作成しました。 その中で、Rx系のライブラリのテストの書き方に困った時、同じくAndroidのViewをバインディングしているJakeのRxBindingのテストの書き方が参考になったので書きたいと思います。 主に、Rxのテストをするときチェックすのは想定通りのイベントがちゃんと流れてきているかです。 ということは、ストリームから流れてきたイベントを持っておく保持してチェックできれば良さそうですね。 ということで、参考にしたRxBindingのテストを踏まえて簡単に見ていきましょう。 使用しているライブラリ テストに使用するライブラリは、基本的にAndroid Testing Support Library 具体的にはここらへん Espresso AndroidJUn
テストケースクラスで以下の用に設定すると、 android.util.Log の結果がAndroid Studioのテストログに出力される。 static { System.setProperty("robolectric.logging", "stdout"); } テスト実行の際のVM optionsに -Drobolectric.logging=stdout を与えても同じだけど、異なるテスト設定を作るたびにこのオプションを設定するのは面倒だ。だから詳細なログが必要なテストケースでのみ有効にするのがいいと思う。コードに記録されるから情報共有もしやすいし。 なおrobolectricで実行すると BuildConfig.DEBUG が false になるので、ライブラリであればログの有効化は外から指定できるようにしたほうがいい。あるいはTimberのようなロガーを使うのも悪くない。 参
Guavaのテストコードを読んでいたらTruthというtesting frameworkが使われていることに気づき、最新の個人プロジェクトで使ってみました。まだアルファ版ですし、自分でも使い続けるかどうか微妙なところですが、試用記録として利点をまとめます。 なお著者がアサーションフレームワークに求めるのは、大人数が関わるプロジェクトにおける「開発者の個性(経験、知識、趣味)に限らず、短時間で保守性が高く直感的なコード・エラーメッセージが書ける」ことです。異なる観点からこのプロダクトを見ると、また違った意見があるかと思います。 assertThat()が必要とされた理由 そもそもassertThat()はなぜ必要なのでしょうか。それはassertTrue(), assertFalse() などのメソッドが生むエラーメッセージが直感的でないからです。 Truthのウェブサイトにのっている例が非
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
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
公式のやることリスト 公式が Wiki にガイドを用意してくれています。基本的にはこのガイドに従ってアップデートしていきます。 足りない部分 しかしアプリケーションによっては足りない部分があり、テストがテストケースとは関係ない部分でバッタバッタと死んでいく事があります。 1. targetSdk が 22 で落ちる 現状 Robolectric 3.0 で対応しているのは 21 までです。targetSdkVersion を 22 にしていると、UnsupportedOperationExceptionでテストができません。 対応するには、@Configアノテーションでバージョンを指定します。 @Config(constants = BuildConfig.class, sdk = 21) public class SomeTest {} 2. MultiDex で落ちる Multidex
以前「Androidのテスティングフレームワークを選定してみる」という記事を書いたのですが、最近久しぶりにEspressoを使ったテストコードを書こうと思って調べていたら、Espressoが2.0から2.2になっていたりして、いつのまにやらTesting Support Libraryが色々と更新されているようでした。 なので、メモがてら少しまとめてみました。 testing-support-libが分割された 以下の2つに分割されたようです。 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
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
golangのtestingパッケージはシンプル主義のgoならではといった、最小限の機能のみを提供しています。実際のところこれまでも(ほぼ)充分な機能を提供してきたわけですが、テスト前の初期化を明確に定義できないなど、不満もありました。 そういうわけで、1.4からこの不満を解決するtesting.MとTestMain(*testing.M)が追加されています。これがかなり最高便利です。 従来のテクニック 当然、これまでもテストの"初期化"や"お片づけ"を書きたいという要求は当然ありました。それに対しては、go testコマンドがファイルをabc...順に読みこむことを利用して、ファイル名を工夫するというちょっと裏ワザ的な手法が一般的でした。 すなわち、最初に実行したいテストが書かれたファイルは「a_test.go」にして、最後に実行したいテストを「z_test.go」とするわけです。この方
apply plugin: 'java' repositories { mavenCentral() } dependencies { testCompile 'junit:junit:4.11', { transitive = false } testCompile 'org.hamcrest:hamcrest-all:1.3' } >gradle dependencies testCompile - Compile classpath for source set 'test'. +--- junit:junit:4.11 \--- org.hamcrest:hamcrest-all:1.3 JUnit 4.11 はデフォルトだと hamcrest-core の 1.3 に依存している。 今回は別途 hamcrest-all を依存関係に追加するので、 transitive = fal
追記(2015/19/7) Robolectric 3.0以降はJVM unit testingの仕組みを利用するようになりました。素の状態よりテストしやすいのでこちらを利用するとよさそうです。このエントリで例に上げたHeliumもRobolectricに移行しました。 三行まとめ Android Studio 1.1からJVM unit testingがサポートされた Android frameworkにあまり依存しないロジックであれば有用 テストファイル書き換えからテスト実行まで数秒でおわるので試行錯誤しやすい 説明 Android SDKがJVMによるテストをサポートしたという話があります: Unit testing support - Android Tools Project Site Gradle Plugin 1.1.0-rc1でJVMでテストを実行出来るようになったらしい
はじめに. 2015.03.13, UIAutomator2.0のリリースアナウンスがあった. We’re pleased to announce the release of UIAutomator 2.0! - Google+ UIAutomator2.0はAndroid Instrumentationベースに生まれ変わり, ./gradlew connectedCheckコマンドでテスト実行することができるようになった. UIAutomator2.0はAndroid Testing Support Libraryにパッケージされた. UIAutomator2.0の導入にはSDK ManagerからAndroid Support Repositoryをダウンロードすること. UIAutomatorはAndroid Developersサイトでも記載されている. Testing Supp
概要 「ART; Android RuntimeになったらMockitoのテスト動かない!」なんてことはないけれども、現状は罠があるという話。詳細はそれぞれの項を参照してください。 引数なしのインターフェイスのメソッドのテストで失敗する NoClassDefFoundErrorが発生してテストがクラッシュする 引数なしのインターフェイスのメソッドのテストで失敗する AndroidのデベロッパーサイトのVerifying App Behavior on the Android Runtime (ART)というページでInvocationHandler.invoke()の挙動が変わった旨の記載があります。 Proxy InvocationHandler.invoke() now receives null if there are no arguments instead of an empt
CatchとはC++のテスティングレームワークの1つです。ヘッダオンリーで使うことが出来ます!簡単! https://github.com/philsquared/Catch 私はこちらのブログを拝見して知りました。 ブログズミ: C++ Testing Framework の Catch を使ってみた Google Testなどと同じようにJUnit形式のxmlを出力することができるのでJenkinsでCIすることも可能です。 触ってみて私が感じたCatchの良い所は、 構造化テストがとても書きやすい JUnit4ライクなassertThatと(カスタム)Matcherがある テストケース名が文字列なので日本語名が付けられる タグを付けるのが簡単で、タグを限定したテストの実行が容易 まだよく分かっていないところと気になるところ パラメータ化、型パラメータ化テストは書けるのか、書けるのなら
Androidのテスト系イベントAndroid Test Casual Talks #1に行ってきました。 Androidのテスト関係ネタはだいたい出尽くした感を持っていたのですが、Espressoやテストケース自動生成など目新しい話、また楽天さんの導入事例の話など、興味深いお話を聞けました。 また、自分でも下記のLTをしてきました。 Androidで使えるモックフレームワーク Androidで使えるモックフレームワーク from Koji Hasegawa スライドに貼ってあるテストコードはgistに上げてあります*1 https://gist.github.com/nowsprinting/7940486 テスト対象(プロダクトコード)は@ITさんの記事「Android Mockを利用してHTTP通信をテストするには」で書いたものです。下記リポジトリにあります。 https://ate
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く