1. Introducción: qué es probar en sandbox

Descripción

Al terminar esta lección vas a poder explicar qué significa exactamente "probar en un sandbox" —con el vocabulario preciso que usa el mercado— y por qué "lo corrí una vez y salió bien" no cuenta como prueba. Vas a tener el mapa completo de las ocho lecciones de este módulo y, sobre todo, vas a conocer el entregable que construimos entre todas: un checklist de pre-producción repetible, que se llena lección a lección hasta que en el proyecto lo ejecutas de punta a punta sobre order-triage.

Esto importa por una razón que ya viste en el Módulo 1, pero que aquí se vuelve el centro: de todas las capacidades que el mercado pide por escrito, probar en un sandbox antes de tocar producción es la más solicitada. Cerca de un tercio de las ofertas serias lo exige con nombre y apellido —"test in a sandbox", "test accounts", "sandbox API keys", "synthetic data", "dry run"—. No es un detalle de higiene: es la línea que separa una demo que "funcionó en la reunión" de un sistema que una empresa se anima a poner a correr con sus pedidos reales. Quien sabe construir workflows hay muchos; quien sabe probarlos sin arriesgar producción ni quemar presupuesto de API es justo el perfil que escasea.

Conexión con el módulo: esta lección es el mapa, no todavía la técnica. Aquí instalamos el problema —por qué "corrió una vez" no es una prueba— y el vocabulario del oficio, y arrancamos el checklist que las lecciones 2 a 7 van llenando: llaves sandbox (lección 2), datos sintéticos (lección 3), dry run y protección de efectos secundarios (lección 4), datos fijados y replay (lección 5), pruebas del agente de IA a costo cero con Ollama (lección 6) y aserciones sobre la salida con el nodo Evaluation (lección 7). La lección 8 junta todo en una pasada completa. Damos por hecho lo de los módulos anteriores: ya versionas order-triage con Git (Módulos 2 y 3) y ya tienes tres entornos aislados —dev, staging, prod— corriendo por Docker Compose, cada uno con su clave de cifrado y sus credenciales (Módulo 4). Este módulo se para sobre esos entornos: probar en sandbox es, en gran medida, sacarle provecho al entorno que ya aislaste.

De "funcionó en la reunión" a "está probado"

Piensa en dos electricistas que instalan el mismo tablero.

El primero conecta los cables, sube la palanca, y como se prende el foco de la sala, dice "listo, funciona" y se va. Probó una cosa, una vez, en la mejor de las condiciones: todo apagado, nadie usando nada, un solo foco. No probó qué pasa cuando se enchufan la lavadora y el microondas a la vez, ni si el corte de emergencia salta cuando debe, ni qué ocurre si alguien mete un cable donde no va. Su prueba fue "se prendió el foco". El día que la familia usa la casa de verdad, el tablero se enfrenta a cosas que él nunca probó.

El segundo, antes de dar por buena la instalación, la somete a una batería de pruebas pensada a propósito: mide la carga con varios aparatos prendidos, provoca a mano una sobrecarga controlada para confirmar que el corte salta, revisa qué pasa con un enchufe mal conectado. Y hace todo eso con el tablero desconectado de la red principal, alimentándolo desde una fuente de prueba, para que si algo sale mal, no queme la casa. Cuando conecta el tablero a la red real, ya sabe cómo se comporta en los casos difíciles, porque los buscó a propósito en un entorno donde equivocarse no cuesta nada.

Los dos "hicieron que funcionara". Solo uno probó la instalación. La diferencia no está en el trabajo con los cables —los dos saben lo mismo—; está en que el segundo trató la prueba como una etapa con método, hecha lejos de la red real, buscando los problemas antes de que los encuentre el cliente.

Eso es probar en sandbox. Un sandbox —la palabra en inglés significa "cajón de arena", como el de un parque donde los niños juegan sin hacerse daño— es un entorno de pruebas aislado, separado de producción, donde puedes correr tu workflow con todas las libertades: datos falsos, credenciales de prueba, y la certeza de que nada de lo que hagas ahí toca la operación real de la empresa. Si el workflow borra un registro, borra uno falso. Si le cobra a una tarjeta, es una tarjeta de prueba que no existe. Si le manda un correo a un cliente, el cliente es inventado. El sandbox es donde puedes equivocarte a propósito para descubrir los problemas mientras equivocarse todavía es gratis.

En esta guía ya tienes tu sandbox: son los entornos dev y staging que levantaste en el Módulo 4. La instancia de dev en tu máquina, con sus credenciales de prueba, es el cajón de arena. Este módulo te enseña a usarlo con método, no a construirlo —eso ya lo hiciste—.

Ejemplo trabajado: la prueba que no era una prueba

Veamos la diferencia con order-triage, el workflow de Cumbre que ya conoces: recibe un pedido por un Webhook, lo clasifica con un nodo AI Agent —aprobar, mandar a revisión manual, o marcar que le falta información— y consulta el CRM con un nodo HTTP Request para registrar el resultado.

La prueba que no era una prueba. El automatizador de Cumbre termina un cambio en order-triage un viernes. Para "probarlo", le manda un pedido de ejemplo —uno bonito, completo, de un cliente que conoce— y ve que el workflow lo clasifica como "aprobado" y lo registra en el CRM. Todo verde. Lo promueve a producción y se va el fin de semana.

Fíjate en todo lo que no probó:

• No probó los casos difíciles. Solo mandó un pedido "feliz". ¿Qué pasa con un pedido de 50 000 pesos que debería ir a revisión manual? ¿Con uno al que le falta el nombre del cliente? ¿Con uno donde el monto viene como texto en vez de número? Nunca lo vio.
• Probó contra el CRM real. Ese "pedido de ejemplo" quedó registrado en el CRM de producción de Cumbre, mezclado con los pedidos de verdad. Si mañana alguien saca un reporte, ahí está su basura de prueba.
• Probó una vez. No tiene forma de repetir exactamente esa prueba. Si la semana que viene hace otro cambio, no puede volver a correr el mismo caso y comparar; tiene que acordarse de qué mandó y armarlo a mano otra vez.
• No verificó la salida, solo que corriera. Vio que el workflow terminó sin error rojo. Pero "terminó sin error" no es lo mismo que "clasificó bien". Si el agente hubiera aprobado un pedido que debía ir a revisión, el workflow igual habría terminado en verde. Corrió; no acertó.

La prueba de verdad. El mismo cambio, probado como se debe: el automatizador prepara un conjunto de pedidos sintéticos que cubren los casos —uno normal, uno grande, uno incompleto, uno con datos sucios—, los corre contra su instancia de dev con la llave sandbox del CRM (nada toca producción), fija esas entradas para poder repetir la prueba idéntica cuando quiera, y al final compara la clasificación del agente contra el resultado que él esperaba para cada caso. Solo cuando todos pasan, promueve.

Qué esperar. La primera forma tarda dos minutos y te deja con una falsa sensación de seguridad. La segunda tarda más la primera vez —hay que preparar los datos y conectar las llaves de prueba—, pero después se repite en segundos, no ensucia producción, y te dice de verdad si el cambio funciona en los casos que importan, no solo en el bonito. Este módulo es, entero, cómo montar la segunda forma sobre order-triage.

El vocabulario exacto del mercado

Vale la pena parar en las palabras, porque son las mismas que vas a leer en una oferta de trabajo y las mismas que un entrevistador espera oírte usar. Cada una nombra una pieza de este módulo.

Sandbox / staging. El entorno de pruebas aislado. En esta guía, tus dev y staging del Módulo 4. "Staging" suele referirse al que más se parece a producción; "sandbox" es el término genérico para "entorno donde probar sin riesgo".

Test account (cuenta de prueba). Una cuenta separada que te da un proveedor —el CRM, la pasarela de pagos, la API de correo— específicamente para probar, desconectada de tus datos y clientes reales. Es la lección 2.

Sandbox API key (llave sandbox / de prueba). Una credencial que apunta al modo de prueba de un servicio. Con ella, las llamadas se ven y se comportan como las reales, pero no producen efectos reales: no se cobra dinero, no se manda un correo de verdad. La lección 2.

Synthetic data (datos sintéticos). Datos falsos pero realistas, generados a propósito para probar, en vez de usar datos reales de clientes. Evitan exponer información personal y te dejan cubrir casos que en tus datos reales tal vez no aparezcan seguido. La lección 3.

Dry run (ejecución en seco). Correr el workflow sin disparar sus efectos irreversibles: sin escribirle al CRM real, sin mandar el correo, sin cobrar. Ya vas a ver que en n8n no hay un botón mágico de "dry run"; es un patrón de diseño que tú montas. La lección 4.

Pinned data (datos fijados). Congelar la salida de un nodo para que en cada corrida el workflow use exactamente esos datos, en vez de volver a llamar a la fuente. Vuelve tus pruebas repetibles e idénticas. La lección 5.

Assertion (aserción). Una afirmación comprobable sobre el resultado: "para este pedido, el agente debe clasificarlo como revisión manual". Probar de verdad es comprobar aserciones sobre la salida, no solo ver que el workflow no truene. Las lecciones 7 y 8, con el nodo Evaluation.

Guárdalas. No son jerga decorativa: son el índice de este módulo y, de paso, media entrevista técnica para un rol de automatización serio. Cuando una oferta dice "experience testing workflows in a sandbox with synthetic data before deploying to production", está pidiendo, palabra por palabra, lo que las próximas siete lecciones te enseñan a hacer. No parafrasea un concepto general; nombra técnicas concretas, y la diferencia entre alguien que las nombra de vuelta con soltura y alguien que responde con generalidades es la diferencia entre pasar el filtro y no pasarlo.

Hay un matiz honesto que conviene marcar desde ya: en el mundo real, estas palabras se usan a veces de forma intercambiable y a veces con distinciones finas, y no todos los equipos las usan igual. "Sandbox", "staging", "test environment" pueden significar lo mismo en una empresa y cosas distintas en otra. No te enredes con la taxonomía perfecta; lo que importa es la idea de fondo —un lugar aislado para probar sin riesgo— y las técnicas concretas para llenarlo. El vocabulario es un mapa para orientarte, no un examen de definiciones.

Por qué "corrió una vez y salió bien" no es una prueba

Esta es la idea que sostiene el módulo entero, así que vale la pena decirla despacio. Correr un workflow una vez, con un dato cómodo, y verlo terminar en verde no es probarlo, por cuatro razones que conviene tener presentes.

Primera: probaste un caso, no el espacio de casos. Un pedido normal es uno de muchos. Los problemas casi nunca están en el caso feliz —para ese fue diseñado el workflow—; están en los bordes: el pedido enorme, el incompleto, el que trae un carácter raro, el que llega dos veces. Una prueba de un solo caso, y encima el más fácil, deja sin mirar justo donde vive el riesgo.

Segunda: "terminó" no es "acertó". Un workflow puede terminar sin ningún error técnico y aun así hacer lo incorrecto. El agente clasifica un pedido de 50 000 pesos como "aprobado automático" cuando debía ir a revisión; el workflow corre feliz, sin una sola raya roja, y acaba de dejar pasar un pedido que un humano debía revisar. Verificar que "corrió" es mirar el motor; verificar que "acertó" es mirar el resultado. Son cosas distintas.

Tercera: si tocaste producción, la prueba tuvo costo. Cuando "pruebas" contra el CRM real, cada corrida deja rastro real: registros de prueba mezclados con los buenos, quizás un correo que sí le llegó a alguien, quizás una llamada al LLM que sí se cobró. Una prueba que ensucia o cuesta no se puede repetir libremente, y una prueba que no puedes repetir libremente no sirve para iterar.

Cuarta: si no la puedes repetir idéntica, no puedes comparar. El valor de una prueba está en correrla otra vez después de un cambio y ver si el resultado sigue siendo el mismo. Si cada corrida usa un dato distinto —porque lo armaste a mano de nuevo—, no estás comparando el cambio; estás comparando también el dato. Las pruebas útiles son reproducibles: misma entrada, para poder atribuir cualquier diferencia al cambio y no al azar.

Junta las cuatro y tienes la definición de trabajo de este módulo. Una prueba de verdad cubre varios casos, incluidos los difíciles; verifica la salida, no solo que corra; se hace en un sandbox aislado a costo cero; y es reproducible. Todo el módulo es montar esas cuatro propiedades sobre order-triage.

Los tres costos de probar contra producción

Cuando alguien "prueba" contra los sistemas reales, no está ahorrándose trabajo: está cargando un costo que se paga después, y a veces con intereses. Vale la pena nombrar los tres, porque cada uno de los primeros puntos del checklist existe para neutralizar uno de ellos. Y en order-triage están los tres, uno por cada pieza del workflow.

El costo de datos: ensuciar lo real. El nodo HTTP Request de order-triage escribe en el CRM de Cumbre. Cada pedido de prueba que corras contra el CRM real queda ahí, mezclado con los pedidos de verdad de las 400 cafeterías. No es un problema el primer día; es un problema el día que alguien saca el reporte de ventas del mes y aparecen tres pedidos de "Café Prueba" por 1 peso, o cuando el equipo de cobranza intenta cobrarle a un cliente que nunca existió. Un dato de prueba en producción no se queda quieto: se propaga a los reportes, a los correos automáticos, a las decisiones. Este costo lo neutralizan las llaves sandbox (lección 2) y los datos sintéticos (lección 3): si la llave apunta al CRM de prueba y el pedido es sintético, la basura cae en un cajón de arena que puedes vaciar.

El costo de dinero: quemar presupuesto real. El nodo AI Agent llama a un modelo de lenguaje, y en producción ese modelo es un servicio de pago que cobra por cada llamada. Probar un agente es, por naturaleza, correrlo muchas veces —cambias un prompt, corres; ajustas algo, corres otra vez; pruebas diez pedidos, son diez llamadas—. Si cada corrida le pega al modelo de pago, iterar sobre el agente se vuelve caro justo cuando más necesitas iterar. Este es el costo más traicionero, porque no deja rastro visible: no ensucia una base de datos, solo aparece en la factura a fin de mes. Lo neutraliza probar el agente a costo cero con un modelo local de Ollama (lección 6): las mismas diez, cien o mil corridas, sin un centavo de factura.

El costo de reputación: efectos que salen al mundo. Algunos efectos secundarios no se quedan dentro de la empresa: le mandan un correo a un cliente real, le cobran a una tarjeta, publican algo. Estos son los peores para probar contra producción, porque no hay "deshacer": el correo ya llegó, el cargo ya se hizo. order-triage no manda correos hoy, pero es fácil que mañana lo haga —"avísale al cliente que su pedido está en revisión"—, y ese día una prueba descuidada le escribe a un cliente real un correo que no debía existir. Este costo lo neutraliza proteger los efectos secundarios (lección 4): diseñar el workflow para que, en modo prueba, la acción irreversible no se dispare.

Fíjate en el patrón: los tres costos son invisibles mientras nada falla, igual que el costo de no versionar que viste en el Módulo 1. Nadie te cobra por probar contra producción el día que lo haces; te cobra semanas después, cuando el reporte sale mal, cuando llega la factura, o cuando un cliente responde "¿de qué pedido me hablan?". El sandbox es, en el fondo, mover esos tres costos de "lo real, después, con intereses" a "un cajón de arena, ahora, gratis".

El checklist de pre-producción que vamos a construir

El entregable de este módulo no es un workflow nuevo: es un checklist de pre-producción, una lista de verificación que corres sobre cualquier cambio antes de promoverlo a prod. Un checklist —como el que repasa un piloto antes de despegar— existe justamente para que no dependas de tu memoria ni de tu estado de ánimo un viernes a las seis. La idea de fondo es simple: un cambio no está listo para producción hasta que pasa todos los puntos, y cada punto es una de las técnicas de este módulo.

Lo vamos a llenar lección a lección. Al arrancar, se ve así —cada casilla la vas a saber marcar al terminar su lección—:

#	Punto del checklist	Lección que lo enseña
1	Corre contra llaves sandbox / cuentas de prueba, nunca contra producción	2
2	Usa datos sintéticos que cubren casos borde y datos sucios, no datos reales	3
3	Los efectos secundarios están protegidos: el workflow no dispara acciones irreversibles al probar	4
4	Las entradas están fijadas para que la prueba sea reproducible e idéntica	5
5	El agente de IA se prueba a costo cero con un modelo local, no quemando presupuesto de API	6
6	La salida pasa aserciones: se verifica que el resultado es el esperado, no solo que corrió	7
7	Todo el pase corre a costo cero y queda evidencia repetible	8

Fíjate en el orden, porque no es arbitrario. Primero preparas el entorno seguro (punto 1: llaves de prueba) y las entradas seguras (punto 2: datos sintéticos). Después proteges las salidas peligrosas (punto 3: efectos secundarios) y las vuelves reproducibles (punto 4: datos fijados). Luego resuelves el caso especial que más duele en el bolsillo, el agente de IA (punto 5: costo cero con Ollama). Solo entonces verificas que la salida es correcta (punto 6: aserciones). Y el punto 7 es la pasada completa que junta todo, con su evidencia. Es el mismo orden en que un cambio se prueba en la vida real: primero lo pones en un lugar seguro, después lo empujas con datos duros, y al final compruebas que lo que salió es lo que debía salir.

Una cosa más sobre el checklist, y conecta con todo lo que ya construiste: no vive en tu cabeza, vive en el repositorio. El checklist de pre-producción es un archivo de texto —un docs/pre-production-checklist.md dentro de cumbre-automations, el repo que versionas desde el Módulo 2— que se llena y se guarda junto al workflow. Que sea un archivo, y no una costumbre mental, tiene tres consecuencias prácticas: cualquiera del equipo lo puede correr igual que tú, queda registrado en Git quién probó qué y cuándo, y es un artefacto que puedes mostrar en una entrevista —"así pruebo antes de promover"— en vez de describirlo de palabra. En la lección 8 vas a ejecutar ese checklist sobre order-triage y a guardar la evidencia; desde ya conviene que lo pienses como parte del repositorio, no como una lista suelta.

Un piloto no repasa su checklist de memoria por más veces que haya volado, y no porque no se lo sepa: lo repasa en papel justamente para que un mal día —cansancio, prisa, distracción— no le haga saltarse el paso que importa. Tu checklist de pre-producción cumple el mismo papel un viernes a las seis, cuando la tentación de "esto es un cambio chico, lo promuevo directo" es más fuerte. El checklist no está para los días en que todo sale bien; está para los días en que tienes prisa.

Y una virtud extra de que sea un archivo: se acumula. Cada vez que un cambio rompe algo que el checklist no atrapó, agregas un punto o un caso nuevo para que la próxima vez sí lo atrape. Con el tiempo, tu checklist deja de ser una lista genérica y se vuelve la memoria de todos los errores que order-triage cometió alguna vez —una lista de "las formas en que este workflow ya se rompió, y que no queremos que se repitan"—. Ese checklist maduro vale más que cualquiera que yo te pudiera dictar, porque está hecho de los tropiezos reales de tu sistema.

Qué NO es este módulo (dónde vive lo que no está aquí)

Vale la pena marcar los límites temprano, porque hay técnicas parecidas que viven en otras guías y conviene no confundirlas.

No es diagnóstico de incidentes en producción. En la lección 5 vas a usar el motor de depuración de n8n —"Debug in editor", "Copy to editor"— pero como herramienta de prueba repetible, no para apagar un incendio en vivo. Investigar por qué falló una ejecución real de producción a las tres de la mañana es tema de la guía de mantenimiento en producción. Aquí el mismo motor se usa antes, en frío, para preparar pruebas.

No es construir el agente de IA. El nodo AI Agent de order-triage ya está construido; en este módulo solo lo probamos a costo cero. Diseñar el agente, sus herramientas y sus bucles es la guía de chatbots y agentes.

No es monitoreo ni control de costos en vivo. Alertas, reintentos, manejo de errores en producción: guía de mantenimiento. Aquí el objetivo es que un cambio llegue a producción ya probado, no vigilarlo una vez que llegó.

No es la promoción en sí. Empujar el cambio ya probado de staging a prod, con su rollback, es el Módulo 6. Este módulo termina justo antes: en "el cambio está probado y listo". El Módulo 6 lo lleva a cruzar la línea.

Errores comunes

Confundir "probé el workflow" con "lo corrí una vez" (conceptual). Qué pasa: alguien manda un dato de ejemplo, ve que el workflow termina en verde, y lo da por probado. Un caso, el más fácil, sin verificar la salida. Por qué pasa: correr un workflow es satisfactorio y rápido; se siente como una prueba aunque no cubra nada. Cómo detectarlo: pregúntate cuántos casos distintos corriste, si alguno era un caso difícil a propósito, y si comprobaste que la salida era la correcta o solo que no hubo error. Si la respuesta es "uno, no, y solo que no hubo error", no probaste, ejecutaste. Cómo corregirlo: es este módulo completo. Una prueba cubre varios casos, incluye los difíciles, verifica la salida y es reproducible.

Probar contra producción "porque es más realista" (conceptual y peligroso). Qué pasa: alguien decide probar contra el CRM real, la pasarela real o el correo real, con el argumento de que así la prueba es más fiel. Y sí es más fiel, y también ensucia datos reales, puede cobrarle a un cliente, mandarle un correo, o gastar presupuesto de API en cada corrida. Por qué pasa: montar el sandbox cuesta un poco al inicio, y saltárselo parece un atajo. Cómo detectarlo: si tu prueba deja algún rastro que no puedas borrar sin consecuencias, estás tocando producción. Cómo corregirlo: eso es exactamente lo que resuelven las lecciones 2 (llaves sandbox) y 4 (proteger efectos secundarios). El realismo se consigue con datos sintéticos representativos y un entorno de staging parecido a producción, no arriesgando la operación real.

Creer que como el workflow ya está versionado, ya está listo para producción (conceptual). Qué pasa: alguien terminó los Módulos 2 a 4 —tiene su workflow en Git, sus entornos separados— y concluye que ya puede promover con confianza. Versionar y aislar entornos es necesario, pero no es probar. Por qué pasa: es fácil confundir "tengo la infraestructura para probar bien" con "ya probé bien". Cómo detectarlo: si puedes decir dónde vive tu workflow y cómo revertirlo, pero no puedes decir con qué casos lo probaste ni cómo verificaste su salida, tienes la infraestructura sin la prueba. Cómo corregirlo: este módulo usa esa infraestructura para lo que fue hecha. Los entornos aislados son el escenario; la prueba en sandbox es la función que montas encima.

Ejercicios

Ejercicio 1 — Traduce el vocabulario a tu situación. Escribe, en una frase cada una, qué serían para un workflow tuyo (o para order-triage de Cumbre) estas cinco cosas: (a) el sandbox, (b) una cuenta de prueba, (c) un dato sintético, (d) un efecto secundario que no querrías disparar al probar, (e) una aserción sobre la salida.

Ver solución

Para order-triage: (a) el sandbox es la instancia de dev que levantaste en el Módulo 4, aislada de producción. (b) una cuenta de prueba sería una cuenta separada del CRM de Cumbre, con sus propios datos falsos, que el proveedor da para probar. (c) un dato sintético es un pedido inventado, por ejemplo { "order_id": "ORD-TEST-001", "customer_name": "Café Prueba", "amount": 1200 }, que no corresponde a ningún cliente real. (d) el efecto secundario peligroso es la llamada HTTP que registra el pedido en el CRM: al probar, no querrías escribir basura en el CRM real. (e) una aserción sería "para un pedido de 50 000 pesos, la clasificación del agente debe ser manual_review".

Por qué funciona: si pudiste llenar las cinco, ya tienes el mapa mental del módulo. Cada una es una lección: la (b) es la 2, la (c) la 3, la (d) la 4, la (e) la 7. La (a) ya la construiste en el Módulo 4. Guarda tus respuestas; en la lección 8 vas a ejecutar exactamente esto.

Ejercicio 2 — Encuentra los cuatro huecos. Vuelve al ejemplo del automatizador que "probó" order-triage mandando un solo pedido bonito contra el CRM real. Sin volver a leer la sección, nombra los cuatro problemas de esa "prueba" y, para cada uno, la propiedad de una prueba de verdad que le faltó.

Ver solución

Los cuatro huecos y la propiedad ausente: (1) probó un solo caso, el fácil → le faltó cubrir varios casos, incluidos los difíciles. (2) probó contra el CRM real → le faltó correr en un sandbox aislado, a costo cero. (3) probó una vez, sin poder repetir la entrada → le faltó ser reproducible. (4) solo vio que corrió, no que acertó → le faltó verificar la salida con una aserción.

Por qué funciona: estas cuatro propiedades —cubre casos, aislada, reproducible, verifica la salida— son la definición de trabajo de "prueba" en este módulo, y las siete casillas del checklist salen de ellas. Si las tienes claras ahora, cada lección que sigue vas a poder ubicarla en cuál de las cuatro ataca.

Ejercicio 3 — Reconstruye el checklist. Sin mirar la tabla, escribe de memoria los siete puntos del checklist de pre-producción, en el orden en que se van a construir. Después compara y marca los que se te escaparon.

Ver solución

(1) Corre contra llaves sandbox / cuentas de prueba, nunca producción. (2) Usa datos sintéticos con casos borde y datos sucios. (3) Los efectos secundarios están protegidos (dry run). (4) Las entradas están fijadas para que sea reproducible. (5) El agente de IA se prueba a costo cero con un modelo local. (6) La salida pasa aserciones. (7) Todo el pase corre a costo cero y deja evidencia.

Por qué funciona: si reconstruiste al menos cinco de los siete, ya internalizaste la progresión: entorno seguro → entradas seguras → salidas protegidas → reproducibilidad → el caso del agente → verificación → la pasada completa con evidencia. Los que más se escapan suelen ser el 4 (fijar datos) y el 6 (aserciones), que son los más nuevos si vienes de "probar a mano". Ese es justo el valor agregado del módulo.

Resumen y siguiente paso

En esta lección viste qué significa probar en un sandbox: correr tu workflow en un entorno aislado de producción —tus dev y staging del Módulo 4— con datos falsos y credenciales de prueba, para descubrir los problemas mientras equivocarse todavía es gratis. Viste la imagen de los dos electricistas —los dos hacen que funcione, solo uno prueba— y por qué "corrió una vez y salió bien" no es una prueba: le faltan las cuatro propiedades que definen a una de verdad —cubrir varios casos incluidos los difíciles, verificar la salida y no solo que corra, correr aislada a costo cero, y ser reproducible—. Aprendiste el vocabulario exacto del mercado —sandbox, test account, sandbox API key, synthetic data, dry run, pinned data, assertion— que es el índice de este módulo. Y recibiste el entregable que construimos entre todas las lecciones: el checklist de pre-producción de siete puntos.

Antes de avanzar deberías poder: definir "sandbox" en una frase; nombrar las cuatro propiedades de una prueba de verdad; y decir de memoria al menos cinco de los siete puntos del checklist.

La lección 2 empieza a llenar el checklist por su primer punto: las cuentas de prueba y las llaves sandbox. Vas a ver cómo los proveedores serios te dan un "modo de prueba" —el test mode de una pasarela de pagos, el sandbox de una API—, cómo separar la llave de prueba de la de producción enganchándola con las credenciales por entorno que ya montaste en el Módulo 4, y —lo más importante— qué cosas no se prueban jamás directamente contra producción, pase lo que pase.

Recursos

• Data mocking and pinning — n8n Docs — la página oficial sobre fijar y simular datos de prueba; la vas a usar a fondo en la lección 5, pero conviene ojearla ya para ver el vocabulario.
• Test and improve AI workflows — n8n Docs — cómo n8n plantea la evaluación de workflows de IA; el corazón de las lecciones 6 y 7.
• Debug and re-run past executions — n8n Docs — el motor de depuración ("Debug in editor" / "Copy to editor") que usamos como herramienta de prueba en la lección 5.
• Source control and environments — n8n Docs — el marco de entornos sobre el que se apoya todo este módulo; repaso útil de lo que montaste en el Módulo 4.