# 自動化されたテスト Stripe の実装で自動化されたテストを使用する方法をご紹介します。 自動化されたテストは、サーバー側とクライアント側のコードのどちらのアプリケーション開発にも共通する部分です。[Stripe Checkout](https://docs.stripe.com/payments/checkout.md) や [Payment Element](https://docs.stripe.com/payments/payment-element.md) などのフロントエンドのシステムには、自動化されたテストを防ぐためのセキュリティ対策が講じられており、Stripe API にもレート制限が設けられています。それでも、疑似データを使用して Stripe のインターフェースと API リクエストの出力をシミュレートし、アプリケーションの動作とその[エラー処理](https://docs.stripe.com/error-handling.md)能力をテストできます。 ## クライアント側のテスト Payment Element を使用した際の取引拒否など、アプリケーションがエラーから復旧できるかどうかをテストしたい場合は、テストコード内で[エラーオブジェクト](https://docs.stripe.com/api/errors.md)をハードコードするか、HTTP レスポンスでモックエラーを返す API サービスを作成することで、シミュレートしたエラーオブジェクトを返すことができます。このエラーオブジェクトは、カードが拒否されたときに [confirmPayment 関数](https://docs.stripe.com/js/payment_intents/confirm_payment)が返す内容を表します。次のセクションでは、シミュレートしたエラーオブジェクトを生成する方法を説明します。 ### エラーオブジェクトを生成する まず、[Payment Element](https://docs.stripe.com/js/element/payment_element) などの Stripe UI 要素を手動で使用して、決済拒否用の[テストカード番号](https://docs.stripe.com/testing.md#declined-payments)を使ってテスト用の PaymentIntent を確定し、エラーオブジェクトを生成します。以下の例のように、確定処理中に発生したエラーをログに記録します。 ```javascript const { error } = await stripe.confirmPayment({ elements, confirmParams: { return_url: 'https://example.com' }, }) ; if (error) { console.log(error) } ``` これにより、以下に示すようなブラウザーコンソールに記録されるエラーオブジェクトが生成されます。`error_code` などのプロパティの詳細は、使用されるカードと、生成されるエラーのタイプによって異なります。 ```json { "charge": "{{CHARGE_ID}}", "code": "card_declined", "decline_code": "generic_decline", "doc_url": "https://docs.stripe.com/error-codes#card-declined", "message": "Your card has been declined.", "payment_intent": {"id": "{{PAYMENT_INTENT_ID}}", …}, "payment_method": {"id": "{{PAYMENT_METHOD_ID}}", …}, "request_log_url": "https://dashboard.stripe.com/test/logs/req_xxxxxxx", "type": "card_error" } ``` Stripe.js 関数と Stripe API を呼び出す代わりに、この Error オブジェクトを返すようにテストを変更します。さまざまな[テストカード](https://docs.stripe.com/testing.md#declined-payments)を使用して、さまざまなエラーコードのエラーを生成し、アプリケーションが各タイプのエラーを正しく処理することを確認できます。 ## サーバー側のテスト サーバー側の API コールをテストするときと同じ方法を使用できます。さまざまなエラー用の Stripe API レスポンスを手動で生成して、バックエンドの自動化されたテストに返されるレスポンスを模擬します。 たとえば、3DS を必要とするオフセッション支払いをアプリケーションが正しく処理できることを確認するテストを作成するには、Payment Method `pm_card_authenticationRequired` を使用し、確定を `true` に設定して Payment Intent を作成することでレスポンスを生成できます。 ```curl curl https://api.stripe.com/v1/payment_intents \ -u "<>:" \ -d amount=2099 \ -d currency=usd \ -d payment_method=pm_card_authenticationRequired \ -d confirm=true \ -d off_session=true ``` これにより、`requires_confirmation` のステータスと、`next_action` のような [3DS 認証](https://docs.stripe.com/payments/3d-secure.md)に関連するプロパティを持つ Payment Intent が生成されます。 ```json { "id": "{{PAYMENT_INTENT_ID}}", "object": "payment_intent", ... "next_action": { "type": "use_stripe_sdk", ... }, ... "status": "requires_confirmation", ... } ``` [支払いライフサイクル](https://docs.stripe.com/payments/paymentintents/lifecycle.md)の複数のステージを反映した PaymentIntent オブジェクトを生成すると、PaymentIntent が別のステータスに移行する際のアプリケーションの挙動をテストすることができます。このアプローチを自動化テストで使用して、システムがさまざまな結果に適切に応答できることを確認します。たとえば、顧客にオンセッションに戻ってもらい、次のアクションが必要な支払いを認証するようにリクエストする応答などがあります。 > #### このアプローチを使用する状況 > > 上記の例はアプリケーションの動作をテストすることを前提としており、継続的インテグレーションテストスイートでの使用に適しています。Stripe API のレスポンスを検証するテストが必要な場合は、テスト環境で API へのリクエストを実行できます。また、Stripe API のレスポンスが変更されていないことを定期的に確認するために API リクエストを使用することもできますが、[レート制限](https://docs.stripe.com/rate-limits.md)を回避するため、これらのテストは頻繁に実行しないでください。