私には、Jersey Test Frameworkの単体テストが動かなくて、大変困った経験があります。
調べてもなかなか解決策が見つからずに、大変苦労しました。
そこで本記事では、実際にJerseyTestが動かなくなった時に私が修正したポイントを紹介します。
※JUnit4で動かすことを前提にしています。
JerseyTestが動かない時にチェックすべき4つのポイント
こちらのサンプルコードで説明します。
import static org.assertj.core.api.Assertions.assertThat;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Application;
import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
// ①org.junit.jupiter.api.Testになっていないか
import org.junit.Test;
// ②publicが抜けていないか
public class SampleResourceTest extends JerseyTest {
@Path("hello")
public static class HelloResource {
@GET
public String getHello() {
return "Hello World!";
}
}
@Override
protected Application configure() {
// ③クラス名は正しいか
return new ResourceConfig(HelloResource.class);
}
@Test
public void test() {
// ④ターゲットのPathが間違っていないか
final String hello = target("hello").request().get(String.class);
assertThat(hello).isEqualTo("Hello World!");
}
}
①org.junit.jupiter.api.Testになっていないか
// ①org.junit.jupiter.api.Testになっていないか
import org.junit.Test;
Eclipseの自動保管ではorg.junit.jupiter.api.Testがimportされることがあります。
org.junit.jupiter.api.TestはJUnit5で実行するときにimportするものです。
JUnit4で実行するときは、org.junit.Testをimportしましょう!
②publicが抜けていないか
// ②publicが抜けていないか
public class SampleResourceTest extends JerseyTest {
JerseyTestを継承したクラスはpublicをつけましょう。
publicがついていないクラスは、実行してもテストが動きません!!
(これもなぜなのか分かりません….)
③クラス名は正しいか
@Override
protected Application configure() {
// ③クラス名は正しいか
return new ResourceConfig(HelloResource.class);
}
Application configure()を@Overrideした時、ResourceConfigのクラスをテスト対象のクラスにしないと動きません。
コピペをすると、クラスを書き換え忘れることがあると思いますので、注意しましょう!
④ターゲットのPathが間違っていないか
@Test
public void test() {
// ④ターゲットのPathが間違っていないか
final String hello = target("hello").request().get(String.class);
assertThat(hello).isEqualTo("Hello World!");
}
targetのPathはしっかり確認しましょう!
Pathが間違っているともちろん正常に動作しないばかりか、テスト対象を間違える事故にもつながります。こちらもコピペで忘れることが多々あると思います。(私はよくやります….)
以上、JerseyTestが動かない時にチェックすべき4つのポイントでした。
また私がJerseyTestで引っかかることがあれば、追記していこうと思います。
コメント