Pruebas Senro

¿Qué hace Pruebas Senro?

Genera exactamente el número de casos de prueba Senro útiles solicitados por el usuario a partir del repositorio que contiene la página que el usuario añadió a Senro. El agente de codificación no ejecuta WebMCP ni las pruebas generadas; Senro ejecuta el conjunto más tarde contra la página registrada.

Flujo de trabajo

1. Confirmar que el repositorio actual contiene la página cuyo comportamiento WebMCP se está probando. Tratar el repositorio como la fuente de verdad.

2. Inspeccionar el repositorio antes de generar cualquier cosa. Excluir .git, directorios de dependencias, salida de compilación, salida de cobertura y archivos generados.

3. Determinar cómo el sitio web expone sus herramientas WebMCP utilizando el código fuente, framework, dependencias, pruebas, fixtures y documentación del propio proyecto. No asumir una API WebMCP, framework, estructura de archivos o patrón de registro en particular.

4. Construir un inventario interno del nombre, descripción, esquema de entrada, anotaciones, implementación y ejemplos disponibles de cada herramienta descubierta.

5. Detenerse y reportar claramente si no se pueden establecer herramientas WebMCP a partir del repositorio. Si hay múltiples sitios o aplicaciones no relacionados, identificarlos y preguntar cuál usar.

6. Leer las rutas, componentes, archivos de datos, fixtures, código de validación, documentación y pruebas existentes relevantes para mapear recorridos de usuario reales y estados de éxito y fallo visibles.

7. Leer references/import-format-v1.md antes de escribir casos de prueba. Usar solo los campos y estructuras documentados allí.

8. Generar exactamente el número solicitado de casos de prueba distintos. Cubrir los recorridos más sólidos del repositorio, incluyendo flujos de trabajo exitosos, condiciones límite, entrada inválida, resultados vacíos, recuperación, acciones con consecuencias y aserciones de estado visible donde la fuente lo admita.

9. Si el repositorio no puede soportar el número solicitado de casos significativos y basados en la fuente, reportar la limitación y detenerse. No inflar el conjunto con escenarios, valores o comportamiento inventados.

10. Usar solo nombres de herramientas y argumentos compatibles con la fuente descubierta. Nunca inventar IDs, cuentas, productos, valores enumerados o estado del backend. Usar pruebas solo con objetivo cuando no se pueda establecer de forma segura un valor de tiempo de ejecución preciso.

11. Usar llamadas a herramientas esperadas solo cuando la fuente admita la ruta esperada. No forzar una trayectoria exacta en un flujo de trabajo donde son posibles múltiples rutas válidas.

12. Crear ./senro si es necesario. Escribir el conjunto en ./senro/test-cases.json. Si ese archivo ya existe en disco, usar el siguiente sufijo numérico disponible, como ./senro/test-cases-2.json. Un archivo eliminado del seguimiento de Git no es una colisión. Mantener los conjuntos directamente en ./senro; no archivar ni mover archivos existentes.

13. Ejecutar el validador estructural previo al vuelo incluido contra el archivo exacto que generaste antes de reportar éxito:

    node <skill-root>/scripts/validate-tests.mjs <output-path>
    

14. Reportar la ruta exacta de salida, el recuento de pruebas, la cobertura de recorridos y cualquier suposición. No afirmar que una prueba esté verificada en tiempo de ejecución; Senro debe ejecutar el conjunto contra la página en vivo.

Reglas de salida

• Escribir un objeto JSON con un arreglo tests.
• Mantener los nombres de las pruebas concisos y con menos de 70 caracteres.
• Escribir solicitudes de usuario naturales. Incluir detalles técnicos solo cuando sean esenciales para el comportamiento que se está probando.
• Cuando la fuente lo admita, variar los modos de conversación, los tipos de evaluación y la complejidad del recorrido. Usar conversaciones con guión para solicitudes explícitas y conversaciones simuladas para aclaraciones o decisiones de múltiples turnos. No forzar la variedad donde no agregue cobertura útil.
• Asignar a las pruebas con guión exactamente un mensaje de usuario inicial.
• Asignar a las pruebas simuladas una lista de mensajes creada vacía y sin seguimientos creados.
• Asegurar que cada prueba tenga un objetivo, una llamada esperada requerida o una verificación de página.
• Describir lo que el agente debe lograr en los resultados exitosos. Usar expectativas de llamadas a herramientas para llamadas y argumentos necesarios, y verificaciones de página para el estado final de la página. No prescribir una ruta de implementación en un resultado cuando existen múltiples rutas válidas.
• Mantener las llamadas de configuración concretas; nunca poner operadores de coincidencia en los argumentos de configuración.
• Usar selectores estables de la fuente para las verificaciones de página.
• Afirmar el estado final estable de la página, no mensajes temporales que acciones válidas posteriores puedan borrar. Verificar el comportamiento intermedio mediante verificaciones de llamadas a herramientas y resultados compatibles o el resultado exitoso.
• Usar expectedCall: null cuando la evaluación de llamadas a herramientas esté deshabilitada. No prohíbe las llamadas a herramientas.
• No modificar el código fuente del sitio web mientras se genera el conjunto.
• No escribir secretos, credenciales o datos privados de clientes en el conjunto.

Referencias

• Formato de importación