Hola a todos, he estado trabajando en esta herramienta de prueba para flujos de trabajo de n8n y agradecería mucho vuestros comentarios sobre qué es correcto e incorrecto.
La herramienta nació de mi frustración al hacer clic en Ejecutar flujo de trabajo y ver que el camino feliz pasaba, asumiendo que todo estaba bien. Esto puede tener sentido si el flujo de trabajo no tiene lógica, pero en cuanto hay un IF o Switch, un bucle, o rutas de error, no es tan útil.
Algunos de los problemas que me afectaron en producción fueron
• Un valor siendo inesperadamente null
• Una salida de error que no va a ningún lugar
• Un nodo Postgres matando toda la ejecución debido a un bloqueo
La herramienta tiene dos partes.
flowproof lint some-workflow.json verifica un flujo de trabajo exportado para detectar posibles problemas sin ejecutarlo. No requiere que n8n esté en funcionamiento, ni credenciales. Verifica nodos inalcanzables, salidas de error que no van a ningún lugar, pinData residual, expresiones sin protección como $json.body.user.profile.email, tokens codificados/URLs locales, y nodos que pueden fallar sin una ruta de error.
La segunda parte, y más interesante, es
flowproof coverage some-workflow.json
que examina las condiciones IF y Switch e intenta encontrar qué entrada haría que se tome cada rama. Para hacerlo, reemplaza nodos externos con fixtures, sin ejecutar llamadas de API reales. Luego ejecuta las pruebas generadas e informa qué ramas fueron realmente alcanzadas.
Por ejemplo, el flujo de trabajo de muestra en el repositorio tiene 7/10 posibles ramas ejercidas. Para las 3 restantes, FlowProof no dice que fallaran, sino que el Switch estaba usando claves de salida para elegir la rama, y por lo tanto no había suficiente información para generar una entrada.
También intento ser preciso sobre la procedencia de cada pieza de información.
Si se tomó una rama IF, se marca como observada. Para bucles, n8n no expone el número de elementos, así que FlowProof tiene que inferirlo de los datos de ejecución. Esto se marca como inferido en lugar de observado.
Al escribir esta herramienta he tenido un falso positivo importante, que me enseñó a ser cuidadoso. Cada subnodo de LangChain fue marcado como inalcanzable, porque las conexiones utilizaban los campos ai_ en lugar de los principales. Fue fácil de arreglar, pero el hecho de que sucediera significa que probablemente hay más casos específicos de n8n que no estoy manejando.
Por eso os pido vuestra ayuda. ¡Si probáis esta herramienta e informa algo obviamente incorrecto, hacédmelo saber! No tenéis que compartir el flujo de trabajo, pero saber el tipo de nodo y lo que FlowProof quería decir ya ayudaría.
Repositorio/instalación
Está bajo licencia MIT, no envía datos a ningún lugar, y no requiere una cuenta. La única advertencia es que mientras que el linting funciona desde JSON, las pruebas de cobertura necesitan una instancia local de n8n para ejecutarse.
Finalmente, esto no trata realmente sobre probar flujos de trabajo de IA. La función Evaluations propia de n8n es mucho mejor para decidir si la respuesta de un LLM es buena. Lo que realmente me interesa son flujos de trabajo comerciales regulares, y si su autor realmente probó todos los posibles escenarios de fallo. categoría para esto