Escribe tus propios escenarios
Los disparadores incluidos cubren los casos que necesita cualquier equipo. Los tuyos cubren los que solo tiene tu producto: el reembolso por el que discute tu equipo de finanzas, el solicitante que tus reglas de riesgo tratan distinto, la respuesta exacta con la que llegó un reporte de bug.
Un escenario es un cuando y un entonces: cuando una solicitud coincide con lo que describes, el backend responde como dijiste.
Dónde viven
Abre el backend, ve a Escenarios, elige un proveedor y usa la pestaña Este backend.
Cada fila es un escenario: un nombre, una o más condiciones, y el resultado. El nombre es una etiqueta. Vuelve junto con el resultado para que sepas qué regla se disparó, y nunca se compara contra él.
Las condiciones de una misma fila son alternativas. Una fila que coincide con dos nombres se dispara cuando llega cualquiera de los dos, no cuando llegan los dos.
Cuál se dispara
Tres capas, probadas en orden:
- Los tuyos
- Lo que trae el proveedor
- El conjunto compartido al que responde cada proveedor
Gana la primera coincidencia, así que escribir un escenario para insufficient_funds reemplaza el comportamiento incluido de ese disparador y deja todo lo demás igual.
Dentro de una capa, el backend elige por un orden fijo de condiciones, no por el orden en que aparecen las filas en la pantalla. Ese orden está en las páginas de pagos y de identidad.
Para descartar las dos capas incluidas y responder solo desde tu propia lista, pon replace: true.
Escribir YAML en su lugar
El editor y el YAML son el mismo documento. Pasa a YAML para todo lo que la tabla no pueda expresar, o para pegar un escenario que te mandó alguien.
Volver al editor reescribe el documento, lo que borra los comentarios. La app lo avisa antes.
Las pestañas De fábrica y Compartido son el lugar obvio para empezar: copia una entrada que ya funciona y cambia lo que necesites.
Qué se revisa antes de guardar
Tu documento se revisa contra el build que el backend corre de verdad, no contra el más nuevo. A un backend fijado a un build más viejo se lo mide con lo que acepta ese build.
La revisión cubre la forma del documento, los nombres de los resultados, los motivos que van con ellos, y los campos por los que puedes comparar. Todo lo que no pueda aceptar se informa por fila, con la fila nombrada, y el guardado se rechaza.
Alcance
Cada sobrescritura pertenece a un alcance de proveedor, en los mismos tres niveles con los que un backend elige proveedores: una marca, una API de ella, o una versión exacta. Gana el más fino.
Escribir contra la marca suele ser lo correcto. Recurre a un alcance de versión cuando dos versiones de la misma API de verdad necesiten respuestas distintas.
Ponerlo en marcha
Guardar almacena el documento. Desplegar es lo que lo pone sobre el backend en marcha, igual que cualquier otro cambio.
Quitar una sobrescritura devuelve a ese proveedor a lo que trae de fábrica.