Reproduisez le bug sur votre propre appareil.
- Enregistrée sur un téléphoneUn testeur tombe sur un bug. La session est enregistrée sur son téléphone et vous est partagée sous forme de fichier.
- Modifiée dans Session StudioOuvrez une session enregistrée et changez un statut, un en-tête ou un corps : une 500, une liste vide, un token expiré.
- Créée de zéro dans Session StudioPas encore de session ni de backend ? Écrivez des réponses mock route par route, puis exportez-les comme une session.
Fichier de session
Votre appareil
1 requête absente de l’enregistrement est partie sur le réseau
Votre app reçoit les réponses du fichier, comme si elles venaient du serveur.
Comment l’utiliser
Quatre étapes, sur l’appareil.
- 1
Apportez le fichier
Importez-le depuis le sélecteur Fichiers dans History, ou utilisez une session enregistrée sur ce téléphone.
HistoryImport trace
- 2
Ouvrez-le dans History
Choisissez la session, puis Replay.
Replay
- 3
Choisissez le mode de matching
Strict compare les query params, Ignore query ne les compare pas. Détails plus bas.
Replay (strict)Replay (ignore query)
- 4
Utilisez votre app
Une bordure rouge indique que le replay est actif. Les requêtes servies portent un badge REPLAY dans Live. Stop arrête le replay.
REPLAYStop
Dans l’onglet Replay, vous pouvez exclure n’importe quelle requête du replay.
Ce qui arrive à chaque requête
Trouvée : réponse du fichier. Pas trouvée : réseau.
Chaque requête lancée par votre app passe les mêmes vérifications, dans cet ordre. La première requête enregistrée qui les passe toutes donne sa réponse.
- 1Le replay est-il actif ?Replay désactivé : rien ne change.non →
- 2Même méthode et même chemin ?GET /v1/transactions ne correspond qu’à GET /v1/transactions. Le domaine n’est pas comparé.non →
- 3Cette réponse peut-elle être rejouée ?La réponse enregistrée doit être du JSON, et la requête ne doit pas être exclue dans l’onglet Replay.non →
- 4Mêmes query params ?Seulement en mode Strict. Ignore query saute cette vérification.non →
oui
Réponse du fichier
La requête ne part jamais sur le réseau. Le SDK construit une réponse HTTP à partir du fichier (statut, en-têtes, corps) et la donne à votre app comme si elle venait du serveur.
Envoyée sur le réseau
Dès qu’une vérification échoue, la requête part comme d’habitude, sans être touchée, et reçoit la réponse du vrai serveur.
Côte à côte : ce qui est comparé
| Requête de votre app | Requête du fichier | ||
|---|---|---|---|
| Méthode | GET | GET | Comparé : identique |
| Domaine | api.lumen-bank.example | uat.lumen-bank.example | Non comparé |
| Chemin | /v1/transactions | /v1/transactions | Comparé : identique |
| Query params | ?sort=date&page=2 | ?page=2&sort=date | Selon le mode |
| En-têtes | Authorization: Bearer eyJ…a91 | Authorization: Bearer eyJ…f07 | Non comparé |
| Corps | — | — | Non comparé |
Modes de matching
Strict ou Ignore query.
Le mode change seulement la comparaison des query params. La méthode et le chemin doivent toujours être identiques.
Replay (strict)
Mêmes paramètres avec les mêmes valeurs. Leur ordre ne compte pas.
Replay (ignore query)
Les paramètres ne sont pas comparés. Utile quand ils changent à chaque appel (un numéro de page, une date).
| Replay (strict) | Replay (ignore query) | |
|---|---|---|
| GET /v1/transactions?sort=date&page=2 | correspond | correspond |
| GET /v1/transactions?page=3&sort=date | ne correspond pas | correspond |
Plusieurs correspondances
Plusieurs requêtes du fichier correspondent. Laquelle est servie ?
Dans un fichier partagé, la même requête est souvent enregistrée plusieurs fois : un écran visité deux fois, un pull-to-refresh. Pour le mode choisi, elles correspondent toutes à la même requête de l’app : elles forment un groupe.
Requête de votre app
GET /v1/accounts
GET /v1/accounts×3même méthode, chemin et query
- HomeViewController10:32:04{ "balance": 1200 }Servie
- TransferViewController10:32:09{ "balance": 1200 }Jamais atteinte
- HomeViewController10:32:15{ "balance": 960 }Jamais atteinte
Le Replay sert la première, dans l’ordre de navigation. Pas la dernière.
Choisissez vous-même la réponse, dans l’onglet Replay
- 1Mettez Sorting sur Grouped : les requêtes qui se correspondent s’affichent ensemble, avec leur nombre.
- 2Désactivez les requêtes que vous ne voulez pas servir.
- 3Gardez active seulement celle que vous voulez : elle passe en premier, et le Replay la sert.
GET /v1/accounts×3même méthode, chemin et query
- désactivéeHomeViewController10:32:04{ "balance": 1200 }Jamais atteinte
- désactivéeTransferViewController10:32:09{ "balance": 1200 }Jamais atteinte
- activeHomeViewController10:32:15{ "balance": 960 }Servie
Les groupes suivent le mode : en Strict, même méthode, chemin et query ; en Ignore query, même méthode et chemin. Session Studio montre les mêmes groupes avant le replay.
Bon à savoir
Les règles derrière le matching.
- Réponses JSON seulementUne requête dont la réponse enregistrée n’est pas du JSON n’est jamais rejouée : elle part sur le réseau.
- Servie tout de suiteLa durée enregistrée n’est pas reproduite : la réponse arrive immédiatement.
- Vérifiez avant de rejouerSession Studio montre, route par route, quelle réponse enregistrée le Replay va servir.
Un problème ouvert
Matcher sur toute la requête.
Notre premier objectif était un matching complet : même méthode, même chemin, mêmes en-têtes, même corps. Sur de vraies sessions, il refusait des requêtes qui étaient clairement les mêmes.
POST /v1/transfers
En-têtes
Content-Type: application/jsonAuthorization: Bearer eyJhbGciOi…Qx7← change à chaque foisX-Request-Timestamp: 1759734610← change à chaque fois
Corps
{
"amount": 240 "beneficiaryId": "b_1029" "nonce": "8f1c2a…"← change à chaque fois}POST /v1/transfers
En-têtes
Content-Type: application/jsonAuthorization: Bearer eyJhbGciOi…L2m← change à chaque foisX-Request-Timestamp: 1760090412← change à chaque fois
Corps
{
"amount": 240 "beneficiaryId": "b_1029" "nonce": "d40b9e…"← change à chaque fois}Comparées partie par partie
- Méthode: identique
- Chemin: identique
- En-têtes: différent
- Corps: différent
Le matching complet dit non. Pourtant, c’est la même requête.
Un token, un horodatage, un nonce : des valeurs qui changent à chaque session, même pour le même utilisateur, suffisent à refuser une réponse qui devrait être servie. C’est pour ça que le Replay compare la méthode, le chemin et, en mode Strict, les query params, et laisse de côté les en-têtes et le corps.
Les pistes que nous avons explorées
- Ignorer une liste de champs connus pour changer (tokens, horodatages, identifiants).
- Vous laisser choisir, route par route, les champs qui doivent être identiques.
- Servir la requête enregistrée la plus proche plutôt qu’une requête identique.
Aucune n’est encore assez bonne, alors le problème reste ouvert. Si vous avez une idée, ou un cas que le Replay gère mal, dites-le-nous.
Nous contacter