Tests
Déclenchez chaque résultat à la demande avant qu'un véritable payeur ne le fasse.
Vous pouvez provoquer volontairement chaque échec qu'un véritable payeur peut rencontrer : fonds insuffisants, code PIN refusé, délai dépassé chez un opérateur, carte refusée ou échec d'un remboursement. La sandbox n'est pas une imitation de l'API. Il s'agit de la même API qui écrit dans une autre base de données. Le code testé est donc celui que vous déployez.
Les trois outils
| Outil | Utilité |
|---|---|
| Clés de sandbox | Exécuter toute votre intégration avec de l'argent de test |
| Numéros et cartes de test | Choisir le résultat produit par la sandbox |
| La CLI | Recevoir des événements live sur localhost et les déclencher à la demande |
Contenu d'une série de tests complète
La plupart des intégrations testent le parcours idéal, puis sont déployées. Les huit cas suivants sont ceux qui provoquent ensuite des problèmes. Chacun ne demande qu'une seule valeur d'entrée. Vos coches sont conservées dans ce navigateur. Une série de tests peut donc s'étendre sur plusieurs jours.
Série de tests dans la sandbox
Forcez-le avec
Voir le guide →+237670000002, sans intervention humaine.Forcez ce résultat avec
+237670000001. Il ne s'agit pas du même échec qu'un refus.Forcez ce résultat avec
+237670000003, le délai dépassé. La commande ne doit pas rester ouverte indéfiniment.+237670000009réussit le paiement, puis refuse le remboursement. Votre registre doit attendre le départ des fonds.Modifiez un caractère du secret et vérifiez que votre endpoint répond
Voir le guide →400.Relancez une livraison et vérifiez qu'elle ne crée qu'une commande, qu'un e-mail et qu'un crédit.
Voir le guide →Un déclenchement de
Voir le guide →payment.succeededlivre cinq événements. Un handler qui en connaît un seul ignore les quatre autres.Une réponse plus lente compte comme un échec. La livraison est tentée cinq fois en seize minutes.
Voir le guide →
Le test de signature est celui que presque personne n'écrit, mais c'est le seul qui protège l'argent.
La boucle qui accélère les tests
# 1
wajub listen --forward-to localhost:3000/webhooks/wajub
# 2
wajub trigger payment.succeeded
wajub trigger payment.failed
wajub trigger refund.succeededChaque déclenchement parcourt toute l'API de sandbox. Votre handler reçoit donc une véritable chaîne d'événements, pas un jeu de données figé.
Vous pouvez tout vérifier dans la sandbox. Les éléments impossibles à vérifier dans cet environnement, comme les clés live, les scopes restreints et les alertes, figurent dans la checklist de passage en live, qui contient sa propre liste.
La sandbox ne teste pas la couverture de vos prestataires
La sandbox accepte chaque canal de sa table d'opérateurs. L'utilisation de ci.wave par votre compte live dépend de vos contrats, pas de votre code. Vérifiez wajub channels avec le profil live avant de supposer qu'un rail est disponible.
Pages associées
- Mode testCe qui est simulé, ce qui est réel et ce qui diffère volontairement.
- Scénarios de testChaque numéro, carte et compte, avec le résultat imposé par chacun.
- Tester les webhooksTrois niveaux, du test unitaire jusqu'à la relance d'une livraison.
- Passer en liveLe changement lui-même et ses conséquences.