HabrにはTestContainersに関する情報はまったくありません。 この記事の執筆時点では、会議の検索結果に発表があり、それだけです。 一方、彼らはすでにGitHubプロジェクトで 700以上のコミット、54人の貢献者、5年の歴史を持っています 。 この5年間、プロジェクトはシークレットサービスとUFOによって慎重に隠されていたようです。 影から光の中に出るときです。

チュクチは読者であり、作家ではありません。 したがって、テキストを書く代わりに、RebelLabsブログから対応する記事を翻訳する許可を求めました。

そのため、ここでは統合テスト用の最新のJavaライブラリであるTestContainersについていくつかの言葉を共有します 。 それ以外は、ZeroTurnaroundにとって統合テストが非常に重要である理由と、統合テストの要件についてはほとんど説明しません。 そしてもちろん、Javaエージェントの完全に機能する統合テストの例があります。 誰かがJavaエージェントコードを目にしたことがない場合、今がその時です。 猫へようこそ！

ZeroTurnaroundでの統合テスト

ZeroTurnaround製品は、Javaエコシステムの多くと統合されます。 特に、JRebelとXRebelはJavaエージェントテクノロジーに基づいており、Javaアプリケーション、フレームワーク、アプリケーションサーバーなどと統合されています。

Javaエージェントを使用すると、必要な追加機能を追加するようJavaコードに指示できます。 パッチの適用後、アプリケーションの動作をテストするには、事前に構成されたJavaエージェントを介して実行する必要があります。 アプリケーションが起動して実行されると、HTTP要求をアプリケーションに送信して、目的の動作を再現できます。

このようなテストを大規模に実行するには、アプリケーションサーバーやアプリケーションが依存する他の外部依存関係など、ランタイムを開始および停止できる自動システムが必要です。 継続的統合環境と開発者のコ​​ンピューターの両方で、ほぼ同じことを実行できるはずです。

その結果、多数のテストが行​​われ、それらはまったく迅速に機能しません。したがって、それらを並行して実行することは間違いありません。 これは、リソースの競合がないようにテストを分離する必要があることを自動的に意味します。 たとえば、同じホスト上でTomcatの複数のインスタンスを実行する場合、ポート使用の競合を回避したいと思います。

このような統合テストでは、小さくて美しいTestContainersライブラリが役に立ちます。 上記の要件に近づいただけでなく、実装後、生産性が大幅に向上しました。

テストコンテナ

TestContainersの公式ドキュメントには次のように書かれています：

「TestContainersは、JUnitテストをサポートするJavaライブラリであり、コアデータベースの軽量の一時インスタンス、SeleniumのWebブラウザー、またはDockerコンテナーで実行できる他のものを提供します。」

TestContainersは、環境のカスタマイズを自動化するためのAPIを提供します。 テストの期間中に必要なDockerコンテナを正確に起動し、テストが完了するとすぐにそれらを消します。 さらに、GitHubのリポジトリにある公式例に基づいたいくつかのデモを見ていきます。

GenericContainer

TestContainersを使用する場合、GenericContainerクラスが非常に頻繁に使用されます。

 public class RedisBackedCacheTest { @Rule public GenericContainer redis = new GenericContainer("redis:3.0.6") .withExposedPorts(6379);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのコンストラクターは、Dockerイメージを示す文字列をパラメーターとして受け取ります。これは今後使用します。 起動時に、TestContainersは適切なイメージを自動的にダウンロードします（以前にダウンロードしていない場合）。

重要な注意： withExposedPorts(6379)



メソッドでは、6379はコンテナがハングするポートです。 次に、コンテナインスタンスでgetMappedPort(6379)



メソッドを呼び出すことにより、対応する関連ポートを見つけることができます。 これをgetContainerIpAddress()



と組み合わせると、コンテナで実行されているサービスの完全なURLを取得できます。

 String redisUrl = redis.getContainerIpAddres() + “:” + redis.getMappedPort(6379);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例のフィールドには@Rule



注釈が付いていることに気付くかもしれません。 JUnitの@Ruleアノテーションは 、このクラスの各テストメソッドでGenericContainer



新しいインスタンスを受け取ることを決定します。 コンテナインスタンスを再利用する場合は、 @ClassRule



アノテーションが存在します。

タスクコンテナ

GenericContainer



継承者は、 GenericContainer



固有のコンテナです。 データアクセスのレベルをテストするために、MySQL、PostgreSQL、およびOracleのコンテナ化されたイメージがすぐに使用できます。

 PostgreSQLContainer postgreSQLContainer = new PostgreSQLContainer("postgres:9.6.2") .withUsername(POSTGRES_USERNAME) .withPassword(POSTGRES_PASSWORD);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この1行だけで、テスト中ずっと残っているコンテナのコピーを取得できます。 テストを実行するマシンでは、データベースを手動でインストールする必要はありません。 同じデータベースの複数のバージョンでテストしたい場合、これは特に大きな利益をもたらします。

自分のコンテナ

GenericContainer



から継承すると、新しいタイプのコンテナを作成できます。 これは、対応するサービスとロジックをカプセル化する場合に非常に便利です。 たとえば、 MockServerを使用して、アプリケーションがHTTPを介して相互に通信する分散システムの依存関係をロックできます。

 public class MockServerContainer extends BaseContainer<MockServerContainer> { MockServerClient client; public MockServerContainer() { super("jamesdbloom/mockserver:latest"); withCommand("/opt/mockserver/run_mockserver.sh -logLevel INFO -serverPort 80"); addExposedPorts(80); } @Override protected void containerIsStarted(InspectContainerResponse containerInfo) { client = new MockServerClient(getContainerIpAddress(), getMappedPort(80)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、コンテナーが初期化された直後にcontainerIsStarted(...)



コールバックが使用され、 MockServerClient



インスタンスが初期化されます。 したがって、独自のコンテナタイプ内のコンテナに固有の実装の詳細をすべて隠しました。 これにより、テスト用のよりクリーンなクライアントコードとよりきれいなAPIが得られました。

さらに、手動で定義されたコンテナが、Javaエージェントをテストするための環境の構築に役立つことがわかります。

TestContainersを使用したJavaエージェントのテスト

このアイデアを実証するために、TestContainersプロジェクトの共同スポンサーであるSergey @bsideup Egorovから親切に提供された例を使用します。

デモアプリケーション

テストアプリケーションから始めましょう。 HTTP GETリクエストに応答するWebアプリケーションが必要です。 脂肪の多いフレームワークは必要ありません。SparkJavaを使用してみませんか？ 楽しさを追加するために、すぐにGroovyでコーディングを始めましょう ここで、このアプリケーションをテストします。

 //app.groovy @Grab("com.sparkjava:spark-core:2.1") import static spark.Spark.* get("/hello/") { req, res -> "Hello!" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、 Grapeを使用してSparkJavaの依存関係をロードし、「Hello！」メッセージで応答する単一のHTTPエンドポイントを定義する単純なGroovyスクリプトです。

Javaエージェント

確認しようとしたエージェントは、Jettyサーバーにパッチを適用し、HTTP応答に追加のヘッダーを追加します。

 public class Agent { public static void premain(String args, Instrumentation instrumentation) { instrumentation.addTransformer( (loader, className, clazz, domain, buffer) -> { if ("spark/webserver/JettyHandler".equals(className)) { try { ClassPool cp = new ClassPool(); cp.appendClassPath(new LoaderClassPath(loader)); CtClass ct = cp.makeClass(new ByteArrayInputStream(buffer)); CtMethod ctMethod = ct.getDeclaredMethod("doHandle"); ctMethod.insertBefore("{ $4.setHeader(\"X-My-Super-Header\", \"42\"); }"); return ct.toBytecode(); } catch (Throwable e) { e.printStackTrace(); } } return buffer; }); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例ではJettyHandler.doHandle



使用しJettyHandler.doHandle



メソッドにJettyHandler.doHandle



適用し、 X-My-Super-Header



を設定する追加コマンドを追加します。

もちろん、Javaエージェントになるには、パッケージに正しくアセンブルし、適切な属性をMANIFEST.MF



ファイルに追加する必要があります。 アセンブリスクリプトは、記事を煩雑にしないためにこれをすべて行います。GitHubに投稿されます。build.gradeファイルの内容を参照してください。

実際に、テスト！

テストは非常に簡単です。アプリケーションにリクエストを行い、特別なヘッダーの応答を確認する必要があります。特別なヘッダーは、理論的にはそこに追加します。 タイトルが見つかり、タイトルの値が期待値と一致する場合、テストは正常に合格しました。 コードを見てください：

 @Test public void testIt() throws Exception { // Using Feign client to execute the request Response response = app.getClient().getHello(); assertThat(response.headers().get("X-My-Super-Header")) .isNotNull() .hasSize(1) .containsExactly("42"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IDEから直接実行することも、コマンドラインから実行することも、継続的な統合環境で実行することもできます。 TestContainersは、エージェントが隔離された環境、Dockerコンテナーにあるように、アプリケーションを起動するのに役立ちます。

アプリケーションを実行するには、GroovyをサポートしたDockerイメージが必要です。 快適にするために、Dockerイメージzeroturnaround / groovyを取得しました。これはDocker Hubにあります。 GenericContainer



から継承して使用する方法は次のとおりです。

 public class GroovyTestApp<SELF extends GroovyTestApp<SELF>> extends GenericContainer<SELF> { public GroovyTestApp(String script) { super("zeroturnaround/groovy:2.4.5"); withClasspathResourceMapping("agent.jar", "/agent.jar", BindMode.READ_ONLY); withClasspathResourceMapping(script, "/app/app.groovy", BindMode.READ_ONLY); withEnv("JAVA_OPTS", "-javaagent:/agent.jar"); withCommand("/opt/groovy/bin/groovy /app/app.groovy"); withLogConsumer(new Slf4jLogConsumer(LoggerFactory.getLogger(script))); } public String getURL() { return "http://" + getContainerIpAddress() + ":" + getMappedPort(getExposedPorts().get(0)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

APIがコンテナのIPアドレスと関連ポート（実際にはランダム化されている）を取得するメソッドをどのように提供しているかをご覧ください。 つまり、テストが実行されるたびにポートが異なります。 したがって、すべてのテストを同時に実行する場合、ポート間で競合は発生せず、テストは崩れません。

これで、Groovyでスクリプトを簡単に作成できる特別なGroovyTestApp



クラスができました。この場合、デモアプリケーションをテストするためのものです。

 GroovyTestApp app = new GroovyTestApp(“app.groovy”) .withExposedPorts(4567); //the default port for SparkJava .setWaitStrategy(new HttpWaitStrategy().forPath("/hello/"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストを実行し、排気を見てください：

 $ ./gradlew test 16:42:51.462 [I] d.DockerClientProviderStrategy - Accessing unix domain socket via TCP proxy (/var/run/docker.sock via localhost:50652) … … … 16:43:01.497 [I] app.groovy - STDERR: [Thread-1] INFO spark.webserver.SparkServer - == Spark has ignited ... 16:43:01.498 [I] app.groovy - STDERR: [Thread-1] INFO spark.webserver.SparkServer - >> Listening on 0.0.0.0:4567 16:43:01.511 [I] app.groovy - STDERR: [Thread-1] INFO org.eclipse.jetty.server.Server - jetty-9.0.2.v20130417 16:43:01.825 [I] app.groovy - STDERR: [Thread-1] INFO org.eclipse.jetty.server.ServerConnector - Started ServerConnector@72f63426{HTTP/1.1}{0.0.0.0:4567} 16:43:02.199 [I] ?.4.5] - Container zeroturnaround/groovy:2.4.5 started AgentTest > testIt STANDARD_OUT Got response: HTTP/1.1 200 OK content-length: 6 content-type: text/html; charset=UTF-8 server: Jetty(9.0.2.v20130417) x-my-super-header: 42 Hello! BUILD SUCCESSFUL Total time: 36.014 secs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストは非常に高速ではありません。 Grapesのダウンロードには時間がかかりますが、これが初めてです。 ただし、これは、HTTPスタックを使用するアプリケーションであるDockerコンテナーを起動し、HTTP要求を行う完全な統合テストです。 さらに、アプリケーションは単独で実行され、非常に簡単です。 そしてこのすべて-TestContainersに感謝します！

おわりに

「それは私のコンピューターで動作します」というのは一般的な言い訳ですが、もはや言い訳になるべきではありません。 コンテナ化技術がますます多くの開発者に利用可能になると、ますます決定的なテストを行うことが可能になります。

TestContainersは、Javaアプリケーション統合テストの狂気の量を減らします。 このライブラリは、既存のテストに簡単に統合できます。 外部依存関係を手動で管理する必要がなくなりました。これは、特に継続的な統合環境では大きな勝利です。

読んだ内容が気に入った場合は、GeekOut Javaカンファレンスの記録をご覧になることを強くお勧めします 。プロジェクトの元作者であるリチャードノースは、開発計画を含むTestContainersの背景情報を提供しています 。 または、少なくともこのプレゼンテーションのスライドを見てください。

---

翻訳者からのいくつかの言葉。

まず、不正確、エラー、タイプミスを見つけた場合、個人アカウントでオレグチャーに行き、すべてをそのまま説明する必要があります。 私は本当にメッセージを読み、バグを修正します。

Java 、新しいテクノロジー、ライブラリに興味がある場合は、Javaカンファレンスにアクセスしてください。 最も近いのはJPointとJBreakです。 ちなみに、ZeroTurnaroundの従業員は、多くの場合、会議で講演者として講演し、プログラム委員会のメンバーとして働いています。

テストに興味がある場合は 、 Heisenbug 2017 Moscowカンファレンスを開催します。これは、1週間半で文字通り開催されます。 Dockerを使用したテストのトピックは、多くのレポートに何らかの形で記載されています 。

TestContainersを使用しますか？ アイデアが好きですか、疑問がありますか？ コメントを書いてください！