自動化されたテスト
自動化されたテストは、サーバー側とクライアント側のコードのどちらのアプリケーション開発にも共通する部分です。Stripe Checkout や Payment Element などのフロントエンドの実装では、自動化されたテストを防ぐためのセキュリティ対策が講じられ、Stripe API にはレート制限があります。それでも、疑似データを使用して Stripe のインターフェイスと API リクエストの出力をシミュレーションし、アプリケーションの動作とそのエラー処理能力をテストできます。
クライアント側のテスト
Payment Element 使用時に取引の拒否などのエラーから回復するアプリケーションの能力をテストする場合は、シミュレーションされたエラーオブジェクトを返すことができます。それには、テストコードにエラーオブジェクトをハードコード化するか、HTTP レスポンスで疑似エラーを返す API サービスを作成します。エラーオブジェクトは、カードが拒否されたときに confirmPayment 関数で返される情報を表します。次のセクションで、シミュレーションされたエラーオブジェクトの生成方法をご覧ください。
エラーオブジェクトを生成する
まず、Payment Element などの Stripe UI エレメントを手動で使用して、エラーオブジェクトを生成します。拒否された支払い用のテストカード番号の 1 つを使用して、テスト環境の Payment Intent を確定します。以下に示すように、確定プロセス中のエラーを記録します。
const { error } = await stripe.confirmPayment({ elements, confirmParams: { return_url: 'https://example.com' }, }) ; if (error) { console.log(error) }
これにより、以下に示すようなブラウザーコンソールに記録されるエラーオブジェクトが生成されます。error_code
などのプロパティの詳細は、使用されるカードと、生成されるエラーのタイプによって異なります。
{ "charge": "{{CHARGE_ID}}", "code": "card_declined", "decline_code": "generic_decline", "doc_url": "https://stripe.com/docs/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 を呼び出す代わりに、このエラーオブジェクトを返すようにテストを変更します。さまざまなテストカードを使用して、さまざまなエラーコードのエラーを生成し、アプリケーションが各タイプのエラーを正しく処理することを確認できます。
サーバー側のテスト
サーバー側の API コールをテストするときと同じ方法を使用できます。さまざまなエラー用の Stripe API レスポンスを手動で生成して、バックエンドの自動化されたテストに返されるレスポンスを模擬します。
たとえば、3DS を必要とするオフセッション支払いをアプリケーションが正しく処理できることを確認するテストを作成するには、Payment Method pm_card_authenticationRequired
を使用し、確定を true
に設定して Payment Intent を作成することでレスポンスを生成できます。
これにより、ステータスが requires_confirmation
で、next_action
などその他のプロパティが 3DS 認証に関連付けられた Payment Intent が生成されます。
{ "id": "{{PAYMENT_INTENT_ID}}", "object": "payment_intent", ... "next_action": { "type": "use_stripe_sdk", ... }, ... "status": "requires_confirmation", ... }
支払いライフサイクルの複数のステージを反映した Payment Intent オブジェクトを生成すると、Payment Intent がさまざまな状態に遷移する際のアプリケーションの動作をテストすることができます。このアプローチを自動化テストで使用して、システムがさまざまな結果に適切に応答できることを確認します。たとえば、顧客にオンセッションに戻って次のアクションが必要な支払いを認証するようにリクエストする応答などがあります。
このアプローチを使用する状況
上記の例はすべて、アプリケーションの挙動をテストしており、継続的な実装のテストスイートでの使用に適しています。Stripe API の応答を確認するためのテストが必要になったときに、テスト環境で API にリクエストを行うアプローチも許容されます。また、Stripe API リクエストを使用して Stripe API の応答が変更されていないことを定期的に確認することもできます。ただし、レート制限を避けるためこれらのテストは頻繁に行うべきではありません。