JUnitでのテストでは、古くは次のように書いてました。 assertEquals("期待値", "実際の値"); で、比較の種類だけassertXxxがあるわけです。 最近だと assertThat("実際の値", is("期待値")); のようにも書けます。 別にどっちでもええやん、とか思ってたのですけど、最近はassertThatのほうを使うようになりました。 というのも、assertEqualsを使おうとすると、補完で結構下まで移動する必要があったのです。 これがassertThatなら、次のようなstatic importにしておけば「as」で補完しても最初にassertThatが出てきます。 import static org.junit.Assert.assertThat; CoreMatchersも次のようにimportしておく必要がありますが、「is」とかは補完するまでも
Java Advent Calendar 2011の16日目です。 前:JSFUnitでテストしよう! | Kokuzawaの日記 次:JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう 書いてること JUnit の話です。使い始めからちょっとだけ踏み込んだ辺りですかね。ちょっとだけなので普通に使ってる方には不要な内容かと思います。私の今持ってる知識を書き殴ってみた感じになりましたが、微妙な理解と残念な文章力の相乗効果でグダグダになってます。お察しください。 内容は Assertion->カスタムAssertion、Matcher->カスタムMatcher、Rule->カスタムRule です。 Assertion JUnitは assert があってこそです。まず org.junit.Assert にある馴染み深い assert を並べてみます。 assertEquals
Abstract JUnit CDI Extensions Core は,JUnit4 で CDI を利用したテストを行うための基本機能を提供します. テストクラスで CDI を利用するには, @RunWith アノテーションに org.seasar.junitcdi.core.runner.CDI クラスを指定します. これにより,CDI コンテナが準備されます. JUnit CDI Extensions では,テストクラス自体も CDI で管理されます. そのため,テストクラスの .class ファイルが作成されるディレクトリには META-INF/beans.xml ファイルが必要です. Maven2 のディレクトリ構成であれば, src/test/resources/META-INF/beans.xml を作成します. ファイルの内容は以下のようにルート要素だけで構いません. 詳細
The Groovy Advantage Groovy simplifies JUnit testing, making it more Groovy, in several ways, including: JUnit is built into the groovy runtime, so you can script JUnit tests for your Groovy and Java classes using Groovy syntax. Groovy provides many additional JUnit assertion statements (see below) Groovy unit tests are easily scriptable with Ant / Maven (see below) Groovy provides Groovy Mocks Se
👋 Hi, I’m @KentBeck 👀 I’m interested in: 3X: Explore/Expand/Extract. As a product matures, the tradeoffs affecting its development change dramatically. What are these changes and how can we respond to them? Power law distributions. Power laws appear despite our best efforts. How should we adapt our tools and techniques to the inexorable laws of nature. Programs as nature. I study the structure a
JUnit を知れば知るほどおもしろくなってきた♪JUnit 4.4 の機能について調べても日本語の情報があんまりなかったから,メモとして書いとこう. さて,まずはassertThatについて.このメソッドの説明は,実際の使用例を見てもらった方がわかりやすいと思うので,まず次の使用例をみてみて.(JUnit 4.4 Release Notesより.) assertThat(x, is(3)); assertThat(x, is(not(4))); assertThat(responseString, either(containsString("color")).or(containsString("colour"))); assertThat(myList, hasItem("3")); 深読みせずに読むと,上から「x は3.」「x は4ではない.」「responseString は,c
blog1.mammb.com のついでに hamcrest の CoreMatchers についてまとめます。 Matchers については blog1.mammb.com まずは基本の is と not 全体的にはこんな感じ。 import static org.hamcrest.CoreMatchers.is; import static org.junit.Assert.assertThat; import org.junit.Test; public class FooTest { @Test public void testFoo() { String actual = "foo"; assertThat(actual, is("foo")); } } not はこう。 String actual = "foo"; assertThat(actual, not("bar"));
@Rule うっかりTwitterでつぶやくと、無関係な方にメッセージを送ってしまって迷惑なJavaのアノテーションですが、JUnit4.7で追加されたらしい @Rule は結構便利な輩です。 乱暴に言うと、テストクラスに @Rule つけた MethodRuleフィールドを書いておけば、テストメソッドをこね回せます。似たようなものに @Before, @After がありますが、これらとの違いはテストメソッドとの距離感です。単純な前後処理ではなくテストメソッド自体を好き放題…とは言わないまでも、ごにょごにょ出来ます。幾つかのクラスが用意されているので、使い方はそれらを見れば大体解るかと*1。自分で MethodRule 実装してもいいんですけど、大抵は用意されているクラスを拡張すれば事足ります。自分で実装する駄目な例は前に書いたおまじないとかです。 ExternalResource 用意
Rules とは JUnit4.7から@Ruleアノテーションが追加されました。@Ruleアノテーションは、org.junit.rules.MethodRuleインターフェースのサブクラスによって定義された振る舞いをテストメソッドに追加します。 MethodRuleの組み込み実装クラス MethodRuleの具象クラスとして、以下のクラスが提供されています。 MethodRule ├ Verifier : オブジェクトの状態が不正な場合にテストを失敗させる │ └ ErrorCollector : 1つのテストメソッドの複数のエラーを集集する ├ ExpectedException : スローされた例外について柔軟なアサーションを行う ├ ExternalResource : サーバの起動停止などの外部リソースの操作を行う │ └ TemporaryFolder: テストメソッド前に一時フ
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり? JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。(もしかしたらもう一つも残ってないかも。) まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
18日(米国時間)、JUnitの最新版となるJUnit 4.4が公開された。JUnitはJavaで開発されたユニットテストフレームワーク。Common Public License Version 1.0のもとに公開されているテストフレームワークで、ユニットテスト用のフレームワークとしては事実上の標準。後発のユニットテストフレームワークに比べて扱いが難しいと批判されることもあるが、4系からはアノテーションを導入するなどしてシンプル化が進められてきた。4.4ではいくつか新機能が導入されているのでここで紹介したい。 新しいアサーションメソッドの導入: assertThat JUnitではテストを記述する方法としてアサーションメソッドを提供している。Assert.assertArrayEquals(...)などがそれにあたるもので、ほかにもassertEquals、assertFalse、ass
Project status Please see the release notes page. Updates are announced via Twitter Follow @mockitojava and mailing list . Mockito downloads and instructions for setting up Maven, Gradle and other build systems are available from the Central Repository. The documentation for all versions is available on javadoc.io (the site is updated within 24 hours of the latest release). Still on Mockito 1.x? S
テストを書いているとモックオブジェクトを使う機会が多いと思います。そのモックオブジェクトは自前で作るよりは、JMockやMockito*1などのフレームワークを利用した方が楽でしょう。 今回は機能的に、ほぼ最強と思われるJMockitを紹介します。 これが、他のモックフレームワークとの機能比較です。 MockingToolkitComparisonMatrix - jmockit - A feature matrix comparing several mocking toolkits. - Project Hosting on Google Code 機能が多ければ使いやすいか。そんなことはないと思います。しかし、これは使いやすいかもと周りの人からお勧めがあったので、実際に使ってどんなところが使えるのか検証してみたので、書いてみます。あと、最後にScalaで使えるか試してみました。 あ、
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く