Aller au contenu

Ironfang Rig

Environnements de test d'intégration

De vrais e-mails. De vrais callbacks.
Votre exécution de test.

Donnez à l'application testée un monde extérieur jetable : une boîte de réception neuve, une URL de callback publique, un endpoint simulé et une route vers votre machine, alloués pour une exécution, avec un enregistrement de tout ce qui leur est parvenu.

Aucune carte requise. Un fichier de suite à côté de votre code, une exécution par test, et des adresses qui cessent de fonctionner dès que l'exécution se termine.

Ironfang Rig / chronologie d'exécutionExemple de résultat

Alloué pour cette exécution

run-k7c3...@inbox.rig.ironfang.uk

hooks.rig.ironfang.uk/h/...

21 événements

dans l'ordre, rien ne manque

  1. #5email.received
  2. #6callback.received
  3. #8connector.request.completed
  4. #16fault.injected
  5. #21connector.request.completed

Transmis à votre machine par un connecteur sortant. Aucun port entrant.

exécution 01a0b9 / TTL 20 min 5 attentes sur 5 satisfaites

Tout ce que reçoit une exécution

Des adresses qui n'existent que pour une exécution

Une suite nomme les identités dont une application a besoin dans le monde extérieur. Chaque exécution en reçoit de nouvelles, impossibles à deviner et propres à elle, qui cessent de fonctionner dès que l'exécution se termine.

Une vraie boîte de réception pour chaque exécution

Chaque exécution reçoit une adresse sous inbox.rig.ironfang.uk qui accepte le courrier de n'importe où. Le message est analysé, son objet, ses liens et ses codes à usage unique sont extraits pour la correspondance, et les octets bruts sont conservés comme preuve.

URL de callback publiques

Enregistrez une URL impossible à deviner auprès du prestataire de paiement, du transporteur ou de votre propre file d'attente. Chaque requête est enregistrée avec sa méthode, son chemin, son corps et une empreinte, et l'expéditeur reçoit immédiatement un 200.

Transmis à votre machine

Liez un callback à un libellé de route et lancez ironfang rig connect à côté de l'application. Les requêtes atteignent un port local par un socket sortant, et la réponse locale est enregistrée. Aucun port entrant, aucun tunnel à configurer.

Endpoints HTTP simulés

Des règles ordonnées comparent la méthode, le chemin, les en-têtes et les champs JSON, et répondent avec le statut, le corps et le délai que vous avez choisis. La même requête reçoit toujours la même réponse.

Des pannes voulues, et le rejeu

Retardez, dupliquez ou abandonnez un callback transmis, ou faites répondre un mock avec le statut de votre choix. Rejouez un callback enregistré pour prouver l'idempotence. Chaque déclenchement est un événement à côté de celui sur lequel il a agi.

Une chronologie que vous pouvez conserver

Chaque observation est un événement avec un numéro de séquence continu. Attendez le suivant, évaluez les attendus à la fin et exportez toute l'exécution en ZIP avec un manifeste d'empreintes.

Les suites persistent. Les exécutions sont jetables. Les ressources ont une durée de vie explicite.

Chaque ressource, chaque événement et chaque limite figure dans la documentation.

La suite en code

Un fichier à côté du code. Une exécution par test.

Le fichier de suite nomme les identités dont l'application a besoin et ce qu'une exécution doit observer. La CLI le synchronise, démarre une exécution, transmet les adresses à votre processus de test sous forme de variables d'environnement, et termine l'exécution avec un verdict quand le processus s'arrête.

  1. Committez ironfang.rig.yaml et lancez ironfang rig run -- npm test.
  2. Vos tests lisent les adresses de la boîte de réception, du callback et du mock dans l'environnement.
  3. Attendez les événements qui vous intéressent ; rejouez ou perturbez volontairement.
  4. Les attendus sont évalués sur la chronologie, et le code de sortie indique la réussite ou l'échec.
version: 1
project: acme-shop
suite: checkout
resources:
  customer_email:
    type: email
  stripe_callback:
    type: callback
    connector:
      route: stripe
expectations:
  - id: order_email
    resource: customer_email
    event: email.received
    match: { subject_contains: "Your order" }
  - id: stripe_forwarded
    resource: stripe_callback
    event: connector.request.completed
    match: { outcome: delivered, status: 200 }

Trois points d'entrée

Depuis le terminal, la CI ou un assistant

Les mêmes exécutions, la même chronologie et les mêmes verdicts, quelle que soit la façon dont l'exécution est démarrée.

  1. Ligne de commande

    ironfang rig synchronise, exécute, attend, rejoue et exporte les preuves. Un binaire statique unique pour Linux, macOS et Windows, avec un fichier de sommes de contrôle par version.

  2. GitHub Actions

    ironfang-ltd/rig-action/start@v1 exporte chaque adresse vers le job ; finish@v1 affiche les verdicts et fait échouer l'étape quand l'exécution échoue.

  3. Outils MCP

    19 outils sur le serveur MCP Ironfang, pour qu'un agent de code puisse démarrer une exécution, préparer le connecteur local, attendre sur la chronologie et armer une panne sans quitter l'éditeur.

Tarifs

Inclus avec votre compte Ironfang

Ironfang Rig est dans sa version initiale. Il n'y a pas d'offre distincte ni de frais pour les exécutions, les ressources ou les événements, dans les limites documentées.

Ce dont vous avez besoin

Une clé API de la plateforme avec les portées Rig, créée dans le portail. Le même compte que pour les autres produits.

Ce qui est limité

Les exécutions durent jusqu'à 24 heures ; 32 ressources et 64 attendus par suite ; 500 messages, 1 000 callbacks et 5 000 appels de mock par exécution.

Ce qui vient ensuite

Une tarification à l'usage sera publiée sur cette page avant que quoi que ce soit ne soit facturé. Rien de ce que vous construisez sur l'API ne change à ce moment-là.

Questions

Ce que fait Ironfang Rig, et ce qu'il ne fait pas

Ironfang Rig exécute-t-il mes tests ?
Non. C'est le monde extérieur auquel vos tests parlent : les adresses, l'enregistrement de ce qui leur est parvenu et les perturbations que vous avez demandées. Votre lanceur de tests, vos assertions et votre application restent les vôtres, où qu'ils s'exécutent.
Comment un callback atteint-il une application sur mon ordinateur portable ?
Par ironfang rig connect, un petit binaire qui contacte la passerelle par un WebSocket sortant avec un jeton à usage unique créé pour l'exécution. La plateforme ne nomme jamais qu'un libellé de route ; ce vers quoi pointe ce libellé est décidé sur votre ligne de commande et ne quitte jamais votre machine.
Y a-t-il quoi que ce soit d'aléatoire ?
Non. Les pannes se déclenchent sur la prochaine observation à laquelle elles s'appliquent, autant de fois que vous l'avez demandé. Attendre un événement lit d'abord la chronologie, si bien que la même chronologie et la même requête renvoient toujours le même événement. Deux exécutions de la même suite face au même trafic donnent les mêmes verdicts.
Que deviennent les données ensuite ?
Les adresses cessent d'accepter quoi que ce soit dès qu'une exécution se termine. Les octets bruts des messages et des requêtes sont conservés sept jours, l'exécution et sa chronologie quatre-vingt-dix jours, puis tout est supprimé. Exportez le paquet de preuves avant cette échéance si une exécution doit lui survivre.

Moins à exploiter. Plus à livrer.

Donnez le monde extérieur à vos tests.

Committez un fichier de suite, démarrez une exécution, et regardez de vrais e-mails et de vrais callbacks arriver sur une chronologie que vous pouvez conserver.

Aucune carte requise. Ironfang Rig enregistre ce qui a atteint les adresses qu'il a allouées ; il n'exécute pas vos tests et n'inspecte pas votre application.