久しぶりにテストコードを書いたのでMEMO〜。 アプリから他のサービスを使っているけど、自動テストの時はそのサービスを使いたくない。 もしくは、テスト対象のクラスから他のクラスのメソッドを呼び出しているが、他のクラスの仕様はそのクラスのテストに委譲しており、今回のテストには含めたくない。 ただ、作成したクラスからサービスや他のクラスに対して、どんな値が渡されたのかはチェックしたい。 例えば、Controllerクラスのテストをする場合、 Controller内で Fukuzatsu クラスの hikisuIppai()メソッドを呼び出しているとする。 でも、hikisuIppai()メソッドの挙動は Fukuzatsu クラス側でテストするから、hikisuIppai() メソッドの「呼び出し回数」と「引数として渡された値」が想定通りに設定されていることだけをテストできればOKとする。 そ
Kotlinに何も考えずにTheoryとDataPointsを使ったテストを書こうとするとデータがJUnitから参照できずエラーになる。 Kotlinにstaticはないのでcompanion objectを作って@JvmFieldをつけることでJUnitから参照できるようになる。 @RunWith(Theories::class) class SampleTest { companion object { @DataPoints @JvmField val data = listOf( 1 to 1, 2 to 4, 3 to 9 ) } @Theory fun testSquare(testData: Pair<Int, Int>) { val result = Calc().square(testData.first) assertEquals("expected:" + testD
JUnit5が案外よさげなので、JUnit5を使うとどんな感じでテストが変わるのか考えてみます。 実際にどこが変わったかとか、使い方自体はいろいろまとめられたブログがあるし、公式ドキュメントも読みやすいのでそちらを。 http://junit.org/junit5/docs/current/user-guide/ メソッドごとのテスト JUnit5でいいのは、Nestedですね。 いままで、いろんなメソッドを対象にしたテストが入り混じってたと思います。 import org.junit.Before; import org.junit.Test; public class PurchaseTest { @Before public void setup() { // 全体のセットアップ // purchase()用のセットアップ // history()用のセットアップ } @Test p
実験的機能っぽいけど、JUnit5でもParameterized Testsができるみたいなので、お試ししてみたよ。 必要なライブラリを追加 junit-jupiter-apiとParameterized Testをするために必要なjunit-jupiter-paramsを追加してあげる。 testCompile 'org.junit.jupiter:junit-jupiter-api:5.0.0' testCompile 'org.junit.jupiter:junit-jupiter-params:5.0.0' テストコードを書いてみる ドキュメントを参考に書いてみた。 Testアノテーションは不要で、ParameterizedTestアノテーションを設定してあげるみたい。 テストデータはValueSourceアノテーションに設定する。ValueSourceアノテーションでは一部の型だ
Multidex 1.0.2でインストルメンテーションテストアプリに対するmultidexingがサポートされました。 https://developer.android.com/topic/libraries/support-library/revisions.html#25-4-0 例えば以下のライブラリを併用すると、64K制限にひっかかります。 androidTestCompile 'org.mockito:mockito-android:2.8.47' androidTestCompile 'com.squareup.assertj:assertj-android-appcompat-v7:1.1.1', { exclude group: 'com.android.support' } androidTestCompile 'com.squareup.okhttp3:mockweb
JUnit 5開発チームは9月10日、Java向けの単体テストツール「JUnit 5.0.0」公開を発表した。プラットフォーム化やモジュラー化を進めているという。 JUnit 5は、クラウドファウンデイングによるプロジェクトとして進められた「JUnit Lambda」を土台に、2006年に公開されたJUnit 4系に続く次世代のJUnitとして進めてきたプロジェクト。約2年の開発期間を経て開発された。Java 8以上をターゲットとしており、様々なテストスタイルを支援する。 JUnit 5ではモジュラー化が進んでいるが、その1つとしてJVMでテストフレームワークをローンチする土台となる「JUnit Platform」を導入した。Console Launcherを利用してコマンドライン、またはJUnit 4ベースのランナーからプラットフォームをローンチし、TestEngineを動かすことができ
背景 現在時刻を使った処理のJUnitテストを書きたい ファイルに時刻が埋まっているなど、チェックしたい時刻の変更が面倒 現在時刻から1分以内の処理時間かどうかを判定したい 判定対象となる時刻はファイルに記載されている この状態では、テストケースでファイルを用意してもその瞬間しか使えない。またファイル自体は自動生成するのはコストが高すぎる。 例えば、、、以下はStorm UI REST APIでアクセスできる情報。このcomponentErrors内にあるtimeを現在時刻と比較するようなJUnitの場合、色々と面倒。 { "executors": 1, "componentErrors": [ { "time": 1458203307000, "errorHost": "hostname", "errorPort": 6701, "errorWorkerLogLink": "http:\
エンタープライズの現場でJUnitテストを書きましょうとプロジェクトを進めてみると、大量のテストコードが出来上がって、CIのジョブが1時間ちかくかかるようになってしまった、なんてことを聞いたことがあります。 これらを速くしようとテストコードをチューニングしたり、ジョブを分けてスレーブで実行しようとしたりするのはわりと骨の折れることです。またスレーブマシンもたくさん用意しなくてはならず、受託開発においてはそんな予算は無いことが多いので、-Dmaven.test.skip=trueというクスリに手を染めてしまうプロジェクトもあるようです。 そんなプロジェクト向けに、準備が非常に簡単で安価に分散実行できてしまうTestStreamerなるものを開発しました。 といっても作ったのはわりと昔です。 http://www.slideshare.net/kawasima/test-streamer 以前
PowerMock + Mockito を簡単に使ってみたのでメモを残しておきます。 やったこととしては、 1. static メソッドのモック化 2. private メソッドのモック化 3. 例外投げるメソッドのモック化 4. コンストラクタのモック化 という感じです。 今回は、Maven 使ってやることにしました。pom.xml の記述内容は以下に。 ・Mockito_maven - powermock - PowerMock is a Java framework that allows you to unit test code normally regarded as untestable. - Google Project Hosting https://code.google.com/p/powermock/wiki/Mockito_maven ※ 以下から .jar をダ
こんにちは！ さて今回は趣向を変えてJ-Unitの話題にしてみます。 PowerMockitoの使い方を少し紹介したいと思います。 外部にHttpリクエストを投げるコードはよくあるかと思います。 単体テストする際にその部分は外部ソース扱いとして切り離して考えるのがベターです。ですが、レスポンス毎のエラー処理などはちゃんとテストしたいですね。 じゃあMock化してしまいましょう。 簡単なHttpRequestを投げるclassです。 テストクラスを作成する際にはhttpClient.executeをMock化して レスポンスや例外を変えればいいと考えますよね。 普通に考えたら簡単そうに見えますが、DefualtHttpClientがMock化できません。 DefualtHttpClient.execute(HttpUriRequest req)メソッドはfinalなのでMockitoではmo
Junitで単体テストをする機会に恵まれたので、備忘録も兼ねて記載。 JUnit暦2週間なのでGreaterな方法もあるはずです。 JUnitでユニットテストをする際にはモックを使う場合がある。 モックを作るツールは多々あるが、今回はMockitoとPowerMockitoを利用する。 クラス名は適当にCarクラスとしておく。 今回紹介するためのクラスなので、面倒くさそうなものを。 public class Car { private static final int FUEL_MAX = 1000; private static Runnable sRunnable; private int mFuel; public Car(int fuel){ mFuel = fuel; } //Constクラスなどによくあるprivateコンストラクタ private Car(){} //publ
はじめに JUnit で例外が発生することをテストしたいときは、 @Test アノテーションで expected を設定するのがたぶん最も簡単な方法かと思います。しかし、例外メッセージの内容を検証したり、さらには Caused By の例外オブジェクトも検証したい、となると、@Test アノテーションでは力不足となります。 そんなときに org.junit.rules.ExpectedException ルールを使うと悩みはだいたい解決しますが、ちょっと使い方がわかりづらかったりします (特に Caused By の例外オブジェクトを検証する場合など)。 なので、Caused By の例外オブジェクトの検証方法を中心に、サンプルコードをメモメモしておきます。 サンプルコードとちょっとした解説 まずはサンプルコードをご覧ください。 import org.junit.Rule; import
始める 初めてのアプリを作成することから始めてみましょう。トレーニング コースを活用して理解を深めるほか、ご自身でアプリ開発を習得することもできます。
渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです（出版が2012年11月）。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを！ JUnit Lambd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
