Gradle から Jetty 利用していて静的リソースをロックして困る場合には - A Memorandum
Windows で Gradle から Jetty プラグインで開発していると、静的リソースを Jetty がロックしてしまう。 jetty-6.XX\etc\webdefault.xml に Jetty のデフォルト設定があるので、WEB-INF/jetty-webdefault.xml にでもコピーして useFileMappedBuffer -> false に書き換える。 <init-param> <param-name>useFileMappedBuffer</param-name> <param-value>false</param-value> </init-param> で gradle から以下の様に webDefaultXml の読み込み先を指定してあげるとよい。 [jettyRun, jettyRunWar, jettyStop]*.with { webDefault
切り替える OSX での JAVA_HOME - A Memorandum
昔は Java Preferences で切り替えていた Java のバージョンですが、最近は java_home コマンドを使って JAVA_HOME 環境変数に設定するのが良い。 java_home コマンド man ページをかいつまむと、 java_home コマンドは、JAVA_HOME 環境変数を設定するための適切なパスを返します。 Javaの環境設定アプリケーションでのユーザーの有効および優先のJVMからこのパスを決定し、ユーザーが rc ファイルに$JAVA_HOMEを設定したり、最小バージョンまたはアーキテクチャの要件を満たす適切なJVMを使用する方法を提供します。 JAVA_HOME 環境変数の指定 以下のように java_home コマンド の結果を export export JAVA_HOME=`/usr/libexec/java_home` バージョン指定したい場
心地良すぎるモックライブラリ Mockito 〜その3〜 - A Memorandum
モックメソッドからの戻り値のデフォルト設定(Since 1.7) 引数をキャプチャしてアサーションで利用する(Since 1.8.0) 部分的に実メソッドを呼び出すモック(Since 1.8.0) モックのリセット(Since 1.8.0) 振舞駆動開発のためのエイリアス(Since 1.8.0) serializableモック(Since 1.8.1) 新しい@Captor, @Spy, @InjectMocks アノテーション(Since 1.8.3) タイムアウト検証(Since 1.8.5) 本記事は、以下の記事の続きです。 blog1.mammb.com モックメソッドからの戻り値のデフォルト設定(Since 1.7) モックメソッドからのデフォルトの戻り値を、モック定義時に Answer として指定することができます。組込で定義されている Answer を使用ることも Foo
心地良すぎるモックライブラリ Mockito 〜その2〜 - A Memorandum
呼び出し順序の妥当性検証 余計なメソッド呼び出しが行われていないことを検証する Mockito のアノテーション 複数回のモックメソッド呼び出しの結果を変化させる コールバック付きの戻り値定義 voidメソッドの振舞を定義するdoXXファミリー 実オブジェクトの動作を変えるspy 本記事は、以下の記事の続きです。 blog1.mammb.com 呼び出し順序の妥当性検証 以下のように、2つのモックがあり、それぞれのモックの add() メソッドの呼び出し順序を検証したい場合、 List firstMock = mock(List.class); List secondMock = mock(List.class); firstMock.add("was called first"); secondMock.add("was called second"); InOrder を使用します。
心地良すぎるモックライブラリ Mockito 〜その1〜 - A Memorandum
EasyMockとの違い Eclipse での利用に際して org.mockito.Mockito モックの利用と妥当性検証 スタブメソッドの定義 引数の照合 メソッド呼び出しの妥当性検証 voidメソッドから例外を返却 API的に EasyMock と大きな違いはありませんが、使用感としては格段に心地良い Mockito。 [:W150] 本家 http://mockito.org/ のドキュメント(というかJavaDoc)をベースにメモ。 EasyMockとの違い Mockito では record モードと replay モードを切り替える必要がない Mockito で作成するモックは常に、EasyMock で言う NiceMock となる スタブメソッドの妥当性検証が常にオプション扱い 大きくは以上となります。具体的に、EasyMock では import static org.e
hamcrest の CoreMatchers 詳細 - A Memorandum
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"));
JUnit4.7 の新機能 Rules とは〜その2 - A Memorandum
先日は、@Ruleの使い方として、VerifierとTemporaryFolderについて見てきました。本日はその他のRuleについて見ていきます。 Timeoutルール org.junit.rules.Timeout は、全てのテストメソッドに、同じタイムアウト時間を設定します。コンストラクタにてミリセカンドでタイムアウトを設定します。 @Rule public MethodRule globalTimeout= new Timeout(20); @Test public void testInfiniteLoop() { for (;;) { ・・・ } TestNameルール org.junit.rules.TestNameルールは、テストメソッドの名前を取得可能にするルールです。以下の例では、testA というテストメソッド名が評価されています。まあ、何に使うの？という所はあります
JUnit4.7 の新機能 Rules とは - A Memorandum
Rules とは JUnit4.7から@Ruleアノテーションが追加されました。@Ruleアノテーションは、org.junit.rules.MethodRuleインターフェースのサブクラスによって定義された振る舞いをテストメソッドに追加します。 MethodRuleの組み込み実装クラス MethodRuleの具象クラスとして、以下のクラスが提供されています。 MethodRule ├ Verifier : オブジェクトの状態が不正な場合にテストを失敗させる │ └ ErrorCollector : 1つのテストメソッドの複数のエラーを集集する ├ ExpectedException : スローされた例外について柔軟なアサーションを行う ├ ExternalResource : サーバの起動停止などの外部リソースの操作を行う │ └ TemporaryFolder: テストメソッド前に一時フ
JUnit 4.8 の新機能 Categories とは - A Memorandum
2009年12月に JUnit 4.8 がリリースされました。このリリースではテストケースにカテゴリを付与することで、実施するテストを選択できるようになっています。カテゴリのために以下の2つのクラスが追加されています。 org.junit.experimental.categories.Categories org.junit.experimental.categories.Category Categories とは Categories は、テストスイートによるテストケースの実行指定を細かく制御できる仕組みです。テスト対象のメソッドやクラスをカテゴリにてマークすることで、テストスイートから実行する対象を細かく制御できるようになります。 Categories の使い方 カテゴリを使用するには、インターフェース、またはスーパークラスにてカテゴリのマーカーを作成します。例えばテストケース毎に
OSGiフレームワーク Apache Felix その1 - A Memorandum
OSGiとは OSGi(Open Services Gateway initiative)とは、Java のモジュールを管理する実行基盤です。元々はシステムの再起動が難しい組み込みシステムにおいて、再起動なくモジュールの入れ替えなどをネットワーク経由にて行うためのものでしたが、最近では、Eclipse や Spring、JBoss の実行基盤としても採用されています。仕様は OSGi Alliance により策定されています。 http://www.osgi.org/Main/HomePage OSGiでは何ができるのか OSGiでは、Java のモジュールをバンドルと呼びます。このバンドルをOSGi実行環境にて管理することで以下のようなことが実現できます。 バンドルの動的なインストール バンドルの依存関係の解決 バンドルのバージョン管理 バンドルによるアクセス制御 バンドルとは バンドル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
