Prueba de Límite de Usuario
Una afirmación sobre un comportamiento visible para el usuario se demuestra al alcanzar el límite de producción más externo afectado por dicha afirmación y comprobar el resultado que observa el usuario. Las comprobaciones unitarias, de componentes y de compilación siguen siendo útiles, pero por sí solas no demuestran una ruta que atraviese un comando, terminal, navegador, canal, demonio, paquete o servicio externo.
Usa la prueba creíble más pequeña que alcance el límite modificado. Una prueba automatizada enfocada es preferible cuando ejercita ese límite de forma confiable. Añade evidencia manual o específica del entorno solo cuando la incertidumbre restante dependa de un terminal real, navegador, sistema operativo, gestor de paquetes, servicio de proveedor, intercambio de credenciales, reconexión o efecto secundario. Reserva una prueba en vivo para el nivel de servicio externo real de pila completa definido en Testing.
Elige el límite
- Indica la acción del usuario y el resultado observable que describe el PR.
- Indica el límite de producción más externo afectado por la afirmación: proceso, terminal, transporte local o remoto, HTTP o navegador, API de canal, API de proveedor, punto de entrada de aprobación, envoltorio de ejecución, propietario del ciclo de vida, instalador o paquete.
- Identifica la evidencia automatizada existente que alcanza ese límite en el head actual.
- Añade solo la evidencia necesaria para la parte no cubierta de la afirmación.
Fresh requiere recuentos de CI cuando alcanza el límite indicado. Sigue CI & Actions para conocer la cobertura requerida actual y las carencias que justifican evidencia adicional.
Cambios en la presentación visual
Los cambios en el texto renderizado, el diseño, el espaciado, la alineación, el ajuste de línea, el recorte, el color, el foco, la selección, el comportamiento adaptable u otro estado visible requieren pruebas obtenidas de la interfaz compatible real. Prueba el estado modificado en una revisión identificable de zerocode, el panel web, la aplicación de escritorio, una CLI o TUI interactiva, un instalador u otra superficie afectada. Registra las dimensiones de la terminal o de la ventana gráfica e incluye una o más capturas de pantalla que protejan la privacidad y muestren el contenido modificado con suficiente contexto del diseño circundante para evaluar el resultado.
Una captura de pantalla generada mediante automatización es aceptable cuando representa la interfaz de producción en el límite indicado. Las aserciones de cadenas, las instantáneas de componentes aislados y las pruebas del renderizador a nivel de funciones auxiliares siguen siendo pruebas de regresión útiles, pero no sustituyen la evidencia de la interfaz real. Una captura de pantalla solo demuestra el estado visible; las afirmaciones sobre interacciones y transiciones también necesitan la acción del usuario y el resultado observado.
Matriz de prueba
| Superficie | Ruta de usuario y límite | Prueba mínima creíble | Agregar prueba manual o específica del entorno cuando |
|---|---|---|---|
| CLI, incluida la guía de inicio rápido de la CLI | Un usuario invoca el comando distribuido, sigue las opciones o las indicaciones de la CLI, y observa la salida, el estado de salida o el estado guardado en los límites del proceso y la terminal. El inicio rápido de la TUI sigue la fila zerocode; el inicio rápido de la web sigue la fila de la puerta de enlace y el panel. | Un script o prueba automatizada que lanza el binario real con un directorio de inicio o de configuración aislado y verifica el resultado visible para el usuario; Testing determina el nivel de suite. | La afirmación depende de indicaciones interactivas, representación en terminal, comportamiento del shell o PATH, permisos de plataforma, o comportamiento de actualización desde el estado existente del usuario. |
| zerocode y transporte de daemon | zerocode se conecta a través del socket Unix local o la tubería de Windows compatible, o a través de WSS remoto, envía una solicitud real y renderiza o persiste el estado devuelto. | Una prueba de integración o de sistema usa el cliente, el servidor y el transporte declarado reales, simulando únicamente los servicios externos. | La afirmación depende de la entrada del teclado, la disposición del terminal, las rutas o permisos de los sockets, TLS o autenticación, el comportamiento de reconexión o el ciclo de vida del proceso del daemon. |
| Gateway, API y panel de control | Un cliente cruza el límite de HTTP, WebSocket o SSE, y un navegador o consumidor de API observa la respuesta, el flujo, el resultado de autenticación o el cambio de estado. | Una prueba a nivel de servidor alcanza la ruta real y la pila de middleware; las afirmaciones del navegador también incluyen una prueba de interfaz de usuario contra ese contrato de ruta. | La afirmación depende del diseño o la interacción del navegador, del comportamiento de las cookies o de la autenticación del navegador, del tiempo de reconexión, de la presentación en streaming o de una restricción de red implementada. |
| Canales | Un evento entrante con formato de canal pasa por el análisis del adaptador y el despacho en tiempo de ejecución, y luego produce la respuesta saliente, el hilo, los medios, la reacción o el estado previstos. | Las pruebas del adaptador cubren las cargas útiles del proveedor y una prueba de sistema cubre la ruta de entrada a salida con la red del proveedor simulada. | La incertidumbre está en el manejo de hilos del proveedor, las reglas de menciones, los límites de medios, la verificación de webhooks, el comportamiento de entrega u otro contrato no disponible en los fixtures. Utiliza una cuenta de prueba dedicada. |
| Proveedores y enrutamiento de modelos | La configuración de usuario y una solicitud seleccionan el proveedor y modelo previstos, y luego exponen el flujo, la respuesta, la alternativa o el error esperados. | Una prueba de integración o de sistema utiliza la configuración real y la ruta de enrutamiento contra un endpoint de proveedor simulado con respuestas precisas según el protocolo. | La incertidumbre es la autenticación del proveedor, el comportamiento de la conexión, las peculiaridades del streaming, los límites de tasa, la disponibilidad del modelo u otro contrato externo no representado por el mock. |
| Aprobación y ejecución de herramientas | Un operador recibe una solicitud de aprobación a través de la CLI modificada, el canal, ACP o el punto de entrada web; la decisión llega a la política común; una llamada aprobada se ejecuta mediante el despachador o wrapper de producción y expone el resultado, recibo, evento del observador, denegación o efecto secundario esperado. | Prueba la puerta de entrada de aprobación modificada a través del gestor de aprobación común, luego dirige la ruta de despacho de producción con una herramienta de prueba inofensiva y accesorios controlados de sistema de archivos o proceso. | La afirmación depende de la presentación en terminal, canal o navegador, permisos del sistema operativo, un programa externo real, señales de cancelación, hardware, acceso a la red o un efecto secundario irreversible. |
| Trabajo en segundo plano | Un trabajo cron, una ejecución de SOP, una tarea delegada o un subagente generado en tiempo de ejecución se inicia a través de su propietario de ciclo de vida real y expone únicamente el comportamiento de estado, persistencia, cancelación, reintento o reinicio que dicha ruta admite. | Conduzca la ruta modificada a través de su propietario documentado y su superficie de estado con un reloj determinista o un worker controlado; use su almacén configurado solo cuando la aserción incluya persistencia. | La afirmación depende de la programación en tiempo real, un reinicio real del servicio, la supervisión de procesos o un entorno externo de programador o de trabajo. |
| Instaladores, paquetes y artefactos de lanzamiento | Un usuario ejecuta el modo de instalador modificado o instala el paquete o archivo producido en un entorno limpio, luego inicia el binario instalado y observa la versión o capacidad esperada. | Pruebe el punto de entrada modificado: ejecute el script de instalación en el modo afectado, o extraiga o instale el artefacto generado y ejecute un comando mínimo posterior a la instalación en un entorno de destino limpio. | El destino está ausente de la CI requerida o la afirmación depende de permisos del gestor de paquetes, integración de shell, firma, notarización, configuración de servicios o comportamiento de actualización específico de la plataforma. |
Informar evidencia
La evidencia de validación debe indicar la revisión probada, la acción del usuario, el entorno, el resultado esperado y el resultado observado. Para los cambios de presentación visual, incluye o enlaza las capturas de pantalla requeridas y registra las dimensiones del terminal o de la ventana gráfica. Enlaza la comprobación automatizada o incluye el comando seguro exacto cuando eso ayude a otro revisor a reproducirla. Las capturas de pantalla demuestran el estado visible, no el comportamiento oculto; los registros solo demuestran la ruta y el resultado que registran.
Cuando un cambio no puede afectar un límite de usuario y no genera ninguna afirmación visible para el usuario, indica que la prueba adicional de límite de usuario no es aplicable. Una refactorización que preserve el comportamiento en una ruta orientada al usuario debe apoyarse en la cobertura de regresión de límites existente; no requiere nueva evidencia manual o específica del entorno a menos que dicha cobertura tenga una brecha identificada.
Utilice datos sintéticos y cuentas de prueba dedicadas para la verificación en vivo. Redacte credenciales, tokens, datos personales y endpoints privados. No utilice cuentas de producción, efectos secundarios irreversibles ni operaciones externas de pago sin autorización explícita.