Postmanを導入してAPIテスト効率をUPした話

Postman導入前の課題

導入前の課題としては以下の2点がありました。

• APIリクエスト作業の冗長化
• APIのリクエスト先の切り替え

⏳ APIリクエスト作業の冗長化

Postman導入前、OpenAPI(Swagger)を利用しており、APIをテストする時などはそこで行っていました。 OpenAPIでAPIのリクエストをする場合、以下の手順を踏む必要がありました。

1. 管理者もしくはユーザーアカウントのログインAPIにリクエストし、アクセストークンを取得
2. 取得したアクセストークンをコピーし、OpenAPIのAuthorizeパラメータにセット
3. テストしたいAPIにリクエスト

そして、この手順を踏むために毎回リクエストボディをデフォルトの状態からテスト用の値へ書き換える作業が発生します。

これが単発のテストであれば気にする程でもない手間ですが、何十何百とこの作業をする事になるので、無視できない作業量になることが多いです。

🔄 APIリクエスト先の切り替え

担当の案件では、開発・ステージング・本番環境の3環境があり、その環境ごとにOpenAPIがサーバーレス環境にデプロイされて利用できる状態です。そのため、各環境のAPIのテストをするためにはそれぞれのデプロイ先の環境(OpenAPI)にアクセスをして、前述の操作を行う流れになります。

なので、一度テストをした環境とは別環境でテストを行う場合、再度別の環境(OpenAPI)にアクセスする必要があり、また1からリクエストの値を取得・設定をして実行する手順を踏む必要があります。

これも繰り返しの作業が増えると、無視できない作業時間になることが多いです。

どのような状態を目指していたか

前述の課題2つを解決し、繰り返しのAPIテストにおけるリクエスト作業の効率化を図ることを目指すべく、以下の要件をクリアすることを目標としました。

• 冗長化した操作を共通・自動化 → データの取得作業を省いて作業効率UP
• リクエスト内容を保持 → 最新のリクエスト内容を保持することで作業効率UP
• リクエスト内容をパターン化(テンプレート化) → リクエストボディの内容をパターン化し、変更作業の省略で作業効率UP
• リクエスト先の切り替えの簡略化 → 環境切り替え・リクエスト値の再設定作業の省略で作業効率UP

OpenAPI(Swagger)

課題の解決の部分でも上げましたが、以下の要件がクリアできることを重要視していました。

• 冗長化した操作を共通化・自動化できる
• リクエスト内容を保持できる
• リクエスト内容をパターン化(テンプレート化)できる
• リクエスト先の切り替えが簡略化できる

ツールが使いやすいという大前提に加えて、重要視する点で上げた要件を満たす機能を持っている点が一番の決め手になりました。

改善したかった課題はどれくらい解決されたか

結果から言いますと、以下の課題は全て解決できたと思います。

• 冗長化した操作を共通化・自動化できる
• リクエスト内容を保持できる
• リクエスト内容をパターン化(テンプレート化)できる
• リクエスト先の切り替えが簡略化できる

どのような成果が得られたか

全体的にAPIリクエストを行うための手順が削減できたため、APIテストの際の作業効率が上がりました。

課題を解決するためのCollectionの構成を設計する部分ですかね。 ここは苦労したというか、時間をかけて試作・改善していった部分になります。

Postmanの導入(特にチームでの導入)を検討する際は、段階的なアプローチをするのが良いと思います。

具体的には、チーム内の各メンバーが個人でワークスペースを作成し、Collectionなどの操作感を確認することにより、ツールの使用感を低コストで把握できます。

次の段階として、チームでの共用ワークスペース利用を検討します。この段階を踏むことでチームでの利用効果をより具体的に評価できるでしょう。

なお、Postmanには既存のCollectionをインポート/エクスポートする機能があるので、有用なCollection構成ができた場合、ファイル形式でチーム内への共有が可能です。

このアプローチにより、4人以上で必要となる有料プランへの移行を急ぐことなく、段階的かつ効果的にPostmanを導入できます。チームのニーズに合わせて柔軟に対応しながら、ツールの価値を最大限に活用することができると思います。

また、ここ最近だとPostman以外にもApidogやThunderClientなどのツールもよく見かけるようになりましたので、用途に合ったツールを選んで行くのが良いと思います。

今後やりたい事として漠然としたイメージですが、以下をやれたらいいなと思っています。

1. 簡易的なユニットテスト
2. Postmanプラットフォームで自社サービスのAPIの公開
3. APIドキュメントをPostmanで一元管理

1. 簡易的なユニットテスト

PostmanにはAPIのレスポンスに対してテストスクリプトを実行する機能があります。 それを利用して、特定のAPIのリクエストパラメータやレスポンスパラメータの仕様変更が発生していないか検知する仕組みを作りたいです。

テストを実行するタイミングとしては、開発時に手動でテストを実行する場合と、プルリクエストを作成した際にGitHub Actionsに埋め込んで、アプリケーションのデプロイ時にテストを自動で実行するケースを想定しています。

2. Postmanプラットフォームで自社サービスのAPIの公開

今後dottでも自社サービスとして何かしら外部にAPIを公開する機会が出てくるかもしれません。

その際に、PostmanプラットフォームでAPIのCollectionを公開してみたいなと思っています。

PostmanプラットフォームにAPIを公開する事で、Postman利用者は公開されているAPIのCollectionを簡単にインポートすることが可能になるため、dottのAPIを利用していただく開発者の方にとって便利になりそうだなと思っています。

3. APIドキュメントをPostmanで一元管理

2と理由が重なる部分がありますが、PostmanのCollectionを設定すると半自動的にAPIのドキュメントを作成してくれるため、APIの仕様が変更になった場合もドキュメント更新がおざなりになる課題を改善できそうという点が1つ。

後は、これも外部にAPIを公開する場合に一緒にこのドキュメントも公開することが可能なので、よりAPIの利用者に親切なサービスにできそうなのでやってみたいというところです。