免責事項
あなたがWebサービスとJava EE開発の第一人者であれば、この記事の特定の多くのことは自明のように思えますが、かつてこれを実装する方法に関する本格的な指示をパブリックドメインで見つけることができず、情報を収集する必要がありました（多くの場合、時代遅れです）さまざまな記事やマニュアルの一部。 したがって、私はこの記事のフレームワークですべてを組み合わせることにしました。
可能な代替案
SoapUIテストの起動を自動化する前に、どのような選択肢があるかを考えてみましょう。 そして、少なくとも2つあります（おそらく、そのうちのいくつかは、この記事の後半で説明するものよりも適しているでしょう）。
- パートタイムサービスがEJB Beanである場合（これは非常に合理的です）、Webサービスの操作に対応するBeanメソッドの呼び出しをテストできます。 このアプローチの利点は、その比較的単純な（使い慣れたJavaオブジェクトでの作業、SoapUI形式の不要なエンティティの欠如）およびトランザクション管理にアクセスできるという事実です（テストの最初にトランザクションを開き、最後にロールバックできるため、常に「クリーン」テストデータベース）。 欠点には、この場合、XMLからDTOへのデータマッピングとして、またエラーが発生する可能性のあるサービスマッピングのようなステージがカバーされないという事実が含まれます。
- Webサービスのクライアントクラスを生成し、リクエストの送信と結果のチェックをJavaコードで直接実装できます。 原則として、機能テストでは、これはSoapUIに代わる優れた代替手段であり、おそらく多少宣言的ではありません。
要点をつかむ
Mavenをビルドおよびプロジェクト管理システムとして、JUnitをテストフレームワークとして使用し、アプリケーションをWildFlyサーバーで実行します。 ただし、これはそれほど基本的なものではありません。TestNGとその他の多かれ少なかれ一般的なアプリケーションサーバーを使用して同じことを行うことができます。
実験的
そのため、最初に簡単なサービスを作成し、実際にテストします。
@WebService(name = "Greeter", serviceName = "Greeter", portName = "Greeter", targetNamespace = "my/namespace") public class Greeter { @WebMethod public String hello(String name) { return "Hello, " + name; } }
ソープイ
次に、SoapUIでプロジェクトを作成し、Webサービスのhello操作が「world」に渡された場合に「Hello、world」が返されることを確認するテストを追加します。 このトピックに関する情報は、たとえばSoapUIの公式Webサイト（ こことここ ）で簡単に見つかるため、このプロセスの詳細には触れません。
その後、メインプロジェクトのテストリソースを含むフォルダーに、Greeter-soapui-project.xmlという名前でSoapUIプロジェクトを保存することを忘れないでください。
ArquillianとJUnit
最も興味深いのは、アセンブリ中にテスト段階でサービスがアプリケーションサーバーに展開され、その後、前に作成したSoapUIテストが実行されることを確認する必要があることです。 Arquillianは、Java EEアプリケーションのテストを少しうまくするために設計されたすばらしいフレームワークで、これを支援します（公式Webサイトの入門ガイドで知り合いを始めることができます）。
このすべての動物園の依存関係をpomファイルに追加します。
<repositories> <repository> <id>soapui</id> <url>http://www.soapui.org/repository/maven2</url> </repository> </repositories> <dependencyManagement> <dependencies> <!-- BOM Arquillian --> <dependency> <groupId>org.jboss.arquillian</groupId> <artifactId>arquillian-bom</artifactId> <version>1.1.8.Final</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> <dependencies> ... <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <!-- Arquillian JUnit. TestNG --> <dependency> <groupId>org.jboss.arquillian.junit</groupId> <artifactId>arquillian-junit-container</artifactId> <scope>test</scope> </dependency> <!-- Arquillian- WildFly-9.0.1.Final. , , , --> <dependency> <groupId>org.wildfly.arquillian</groupId> <artifactId>wildfly-arquillian-container-managed</artifactId> <version>1.0.1.Final</version> <scope>test</scope> </dependency> <!-- SoapUI SoapUI- --> <dependency> <groupId>com.smartbear.soapui</groupId> <artifactId>soapui</artifactId> <version>5.1.3</version> <scope>test</scope> </dependency> </dependencies>
コンテナ/アプリケーションサーバー用のアダプタについても言及する必要があります。 多かれ少なかれ完全なアダプターのリストがプロジェクトwikiで提供されており、個々のアダプターの構成パラメーターを確認することもできます。 ただし、このリストは明らかにサポートされていないため（最後の変更は2014年8月）、したがって、コンテナーの最新バージョンのアダプターに関する情報を個別に検索する必要があります。 一般に、すべてのアダプターは3つのクラスに分類できます。
- 埋め込みコンテナ用のアダプター、
- リモートコンテナアダプタ
- および管理されたコンテナアダプタ。
管理されたコンテナはCI環境で最も有用です
- 組み込みとは異なり、これらは本格的なコンテナであり、製品上にあるものとは異なる動作をする可能性を減らします。
- リモート（おそらくこれが唯一の基本的な違い）とは異なり、ライフサイクルを管理する機能を提供します。 テストの開始時にコンテナを開始し、終了後に停止することができます。
したがって、アダプターの管理バージョンを選択します。 ただし、CI環境に加えて、テストが開始される前でもサーバーを起動できる開発マシンでテストを実行する必要があります。 デフォルトでは、Arquillianはコンテナがすでに実行されていることを誓います。安心させるには、allowConnectingToRunningServerパラメーターをtrueに設定する必要があります。
<?xml version="1.0" encoding="UTF-8"?> <arquillian xmlns="http://jboss.org/schema/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd"> <container qualifier="jbossas" default="true"> <configuration> <property name="allowConnectingToRunningServer">true</property> </configuration> </container> </arquillian>
サーバーを起動するには、ArquillianはWildFlyのインストールへのパスを知っている必要があります。 デフォルトでは、環境変数JBOSS_HOMEから取得されます（ただし、arquillian.xmlで再定義できます）ので、忘れずに目的の値に設定してください。
すべての依存関係を指定し、Arquillianを構成したので、すべての作業を実行するテストクラスの作成に最終的に進むことができます。
// Arquillian JUnit @RunWith(Arquillian.class) public class GreeterIT { /* , Deployment, , Arquillian . , . , , testable false. */ @Deployment(testable = false) public static Archive<?> createDeployment() { /* ShrinkWrap , , , . , , ( ) , , Maven-. */ return ShrinkWrap.createFromZipFile(WebArchive.class, new File("target/ws-autotesting.war")); } @Test public void testGreeter() throws Exception { SoapUITestCaseRunner runner = new SoapUITestCaseRunner(); // SoapUI runner.setProjectFile("src/test/resources/Greeter-soapui-project.xml"); // JUnit runner.setJUnitReport(true); // runner.setPrintReport(true); // failsafe runner.setOutputFolder("target/failsafe-reports"); runner.run(); } }
SoapUIプロジェクトでは、ホストとしてlocalhostが指定されており、テスト中にWebサービスがローカルの管理対象サーバーにデプロイされるため、すべてが正常に機能することに注意してください。 ただし、リモートサーバーに展開した場合は、SoapUIが要求を送信するアドレスを再定義する必要があります。 この場合、testGreeterメソッドは次のようになります。
@Test public void testGreeter(@ArquillianResource URL serverUrl) throws Exception { ... runner.setHost(serverUrl.getHost() + ":" + serverUrl.getPort()); ... }
フェイルセーフ
ビルドプロセス中にテストを実行できるように、Mavenを構成するだけです。 フェイルセーフプラグインはこれに役立ちます。 テストクラスの名前は「IT」で終わります。これは、Failsafeによって起動された統合テストの命名規則に対応しているため、pomファイルでプラグインを構成するだけです。
<properties> <skipITs>true</skipITs> </properties> ... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.18.1</version> <configuration> <!-- , VM --> <forkCount>1</forkCount> <reuseForks>false</reuseForks> <redirectTestOutputToFile>false</redirectTestOutputToFile> <!-- , it (.. )--> <skipITs>${skipITs}</skipITs> </configuration> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> </plugin> ... </plugins> </build> <profiles> <profile> <id>it</id> <properties> <skipITs>false</skipITs> </properties> </profile> </profiles>
以上です！
これで、MavenはitプロファイルでビルドするときにCI環境でテストの実行を自動的に開始し、開発者はお気に入りのIDEで緑色のバービューを楽しむことができます。
この記事のソースはすべてgithubにあります。