SoapUI の代替：デスクトップ前提の API テストスイートからの移行

SoapUI が今も得意とすること

• SOAP と WSDL。 最近のツールの多くが後回しにするか、そもそも扱わない領域を、本格的にサポートしています。

• 複雑なメッセージの構築。 XML の踏み込んだ操作とアサーションに対応しており、これはエンタープライズ統合がまさに必要とするものです。

• モックサービス。 開発の相手となるダミーのエンドポイントを立ち上げる機能を、標準で備えています。

SOAP 中心の業務であれば、何を手放すことになるのかを慎重に見極めてください。ここでの対応範囲の広さは本物です。

それでも代替が探される理由

SoapUI の代替を比較する観点

状態の扱いの仕組みについては、 API テストのドキュメント。

移行前に確認すべきこと

実際に SOAP なのはどれかを棚卸ししてください。スイートの 9 割が REST で、残りは何年も誰も触れていないレガシーな SOAP エンドポイントが数個だけ、という発見はよくあります。そうであれば、移行の規模は見た目よりずっと小さく、残った SOAP は今の場所に置いたままで構いません。

本当に SOAP 中心であれば、使い勝手を理由に移行すべきではありません。対応範囲の広さのほうが重要です。

候補をどう評価するか

意図的に壊してみてください。保存しても値が残らなくなるといった、実際に起こりうるリグレッションを仕込み、それぞれの候補が何を報告するかを見ます。テストは失敗するか。その失敗は実際の食い違いを言い当てているか。修正する人はその出力を起点に、経緯を一から組み立て直さずに着手できるか。アサーションに到達しなかった実行を成功と報告するツールは、唯一意味のあるテストに落第しています。

移行前にスイートを分割する

うまくいく移行が一度にすべてを動かすことは、ほとんどありません。そして分割は見た目より簡単です。SOAP と REST が同じテストの中で入り混じることは、めったにないからです。

まず、すべてのテストケースをプロトコルごとにタグ付けするところから始めます。多くのチームで見つかるのは 3 つのグループです。レガシーサービスに対する本物の SOAP、新しいサービスに対する REST、そしてワークフローが世代をまたぐために両方に触れる少数のケースです。1 つ目のグループは今の場所に残り、スイート全体をそこに留めておく理由ではなくなります。2 つ目は移行します。3 つ目は個別に見る価値があり、必要からではなく都合で 1 つにまとめられていた 2 つのテストに分かれることが少なくありません。

先にタグ付けをしておけば、移行に目に見える終わりが生まれます。これが、完了するプロジェクトと、1 年後もまだ中途半端なままのプロジェクトを分ける違いです。

始め方

何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインでできるそれ以外の操作については、 CLI リポジトリ。

• GitHub App は、TestSprite のダッシュボードで設定する webhook です。パイプラインがすでに発行しているデプロイイベントを待ち受けるため、リポジトリ側は何も変わりません。

• GitHub Actions は、ターミナルから設定し、自分のワークフローの中にステップを組み込みます。

TestSprite が REST 側でカバーすること

スイートの REST 部分がこれまで担っていたことはすべてカバーしつつ、ワークフローはデスクトップではなくパイプラインに合わせてあります。テストケースはプロジェクト内に置かれ、自然な言葉で記述され、同じやり方で磨き込めるため、変更はほかの人がレビューできるものになります。

状態の扱いは製品機能として提供されます。Auto-Authentication、Dynamic Variables、Dependency Chains、Auto-Cleanup がそれにあたり、SoapUI では自分で保守するプロパティ、転送ステップ、テストケースの順序、teardown スクリプトに相当します。

実行はデプロイ、または自分のワークフローからトリガーされ、結果はプルリクエストへのコメントとして届きます。SOAP の資産は適切にサポートされている場所に残り、移行は 1 年後も中途半端なままになるのではなく、目に見える終わりを迎えます。