Tests automatiques

Les tests automatiques font partie intégrante du processus de développement d’applications, tant pour le code côté serveur que côté client. Les interfaces front-end, telles que Stripe Checkout ou le Payment Element, sont soumises à des mesures de sécurité visant à empêcher ces tests automatiques. En outre, le nombre de requêtes aux API Stripe que vous pouvez effectuer est limité. Cependant, vous avez la possibilité de simuler la sortie de nos interfaces et des requêtes API à l’aide de données fictives afin de tester le comportement de votre application ainsi que la gestion des erreurs.

Tests côté client

Si vous souhaitez tester la capacité de votre application à gérer les erreurs (par exemple, les refus de transactions avec utilisation du Payment Element), vous pouvez renvoyer un objet Error simulé en codant en dur des objets Error dans votre code de test, ou bien en créant un service d’API qui renvoie des erreurs fictives dans une réponse HTTP. L’objet Error représente le résultat de la fonction confirmPayment en cas de refus de la carte. Pour savoir comment générer un objet Error simulé, consultez la section suivante.

Générer un objet Error

En premier lieu, utilisez un élément d’interface utilisateur Stripe tel que le Payment Element pour générer manuellement un objet Error en confirmant un PaymentIntent en mode test à l’aide d’un numéro de cartes de test pour paiement refusé. Consignez l’erreur au cours du processus de confirmation, comme indiqué ci-après.

const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: {
    return_url: 'https://example.com'
  },
}) ;
if (error) {
  console.log(error)
}

Cette action génère un objet Error consigné dans la console du navigateur, similaire à l’exemple ci-après. Les valeurs des propriétés telles que error_code dépendent de la carte utilisée et du type d’erreur généré.

{
  "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"
}

Modifiez vos tests de façon à ce qu’ils renvoient cet objet Error plutôt que d’appeler des fonctions Stripe.js et les API Stripe. Vous pouvez utiliser plusieurs cartes de test pour générer différentes erreurs et différents codes d’erreur afin de vérifier que votre application traite correctement chaque type d’erreur.

Tests côté serveur

Vous pouvez recourir à la même approche lorsque vous testez des appels aux API côté serveur. Générez manuellement des réponses de l’API Stripe pour diverses erreurs et simulez la réponse renvoyée dans les tests automatiques back-end.

Par exemple, si vous souhaitez rédiger un test destiné à vérifier que votre application traite correctement les paiements hors session nécessitant 3DS, vous pouvez générer la réponse en créant un PaymentIntent à l’aide du PaymentMethod pm_card_authenticationRequired et en définissant confirm sur true.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=2099 \
  -d currency=usd \
  -d payment_method=pm_card_authenticationRequired \
  -d confirm=true \
  -d off_session=true

Cette opération génère un PaymentIntent à l’état requires_confirmation, ainsi que d’autres propriétés associées à l’authentification 3DS telles que next_action.

{
  "id": "{{PAYMENT_INTENT_ID}}",
  "object": "payment_intent",
  ...
	"next_action": {
        "type": "use_stripe_sdk",
    ...
  },
  ...
  "status": "requires_confirmation",
  ...
}

En générant des objets PaymentIntent reflétant différentes phases du cycle de vie des paiements, vous pouvez tester le comportement de votre application tout au long de l’évolution des PaymentIntents. Utilisez cette approche dans le cadre de vos tests automatiques afin de vérifier que votre intégration réagit correctement à différentes situations, par exemple lorsque votre client rouvre une session pour authentifier un paiement qui nécessite une action de sa part.