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 cuyo resultado o riesgo incluya diseño, espaciado, alineación, ajuste de línea, recorte, tipografía, color, foco, selección, comportamiento responsivo, composición gráfica u otro estado sensible a la presentación requieren evidencia de la interfaz real compatible. Ejecuta 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. Usa dimensiones representativas de terminal o de ventana, e incluye una o más capturas de pantalla que respeten la privacidad y que muestren el contenido modificado con suficiente diseño circundante para juzgar el resultado. Registra dimensiones numéricas solo cuando sean necesarias para reproducir o evaluar un problema concreto de presentación, como el ajuste de línea, el recorte o el diseño responsivo.

El texto renderizado por sí solo no constituye automáticamente un cambio de presentación visual. Un cambio de interfaz renderizada que sea solo semántico puede usar evidencia automatizada de exact-head obtenida de la salida final de la interfaz compatible, en lugar de una captura de pantalla, cuando no pueda afectar al diseño, los estilos, el recorte, el ajuste de línea, el foco, la selección ni el comportamiento de interacción. La evidencia debe ejercitar la interfaz real a través de su renderizador final, observar la salida que reciben los usuarios e identificar el estado modificado y el resultado observado. La inspección del código fuente, la composición previa al renderizado, las instantáneas solo de componentes y las aserciones a nivel de helper no cumplen este requisito. Una preocupación concreta de presentación restablece el requisito de captura de pantalla de la interfaz real indicado anteriormente. Un CLI, stdout, stderr o registro de texto plano no interactivo, sin estilos y determinista puede usar la salida exacta de la interfaz compatible cuando no haga ninguna afirmación sensible a la presentación y ningún revisor haya identificado una preocupación concreta de presentación. Registra el contexto relevante de formateo de salida, como la configuración regional y el ancho del terminal.

Una captura de pantalla generada por automatización es aceptable cuando muestra la interfaz de producción en el límite declarado. Para la evidencia renderizada solo semántica sin captura de pantalla, la comprobación automatizada debe observar la salida final de la interfaz compatible, como un resultado renderizado en el navegador que tenga en cuenta la visibilidad, o la salida final de celdas de terminal del renderizador TUI real. Las aserciones de cadenas, la composición previa al renderizado, las instantáneas solo de componentes y las pruebas del renderizador a nivel de utilidades auxiliares siguen siendo útiles como evidencia de regresión, pero no sustituyen ese límite. Una captura de pantalla solo demuestra el estado visible; las afirmaciones sobre interacción y transición también requieren la acción del usuario y el resultado observado.

Evidencia reutilizada tras una actualización

La evidencia existente de capturas de pantalla de la interfaz real no necesita rehacerse solo porque una rama se haya fusionado o rebaseado, o porque cambiaran sus metadatos o el cuerpo del PR. Revise el diff intermedio frente a los estados capturados. Reutilice la evidencia cuando ese diff preserve el comportamiento renderizado de la interfaz y sus entradas sensibles a la presentación, y mantenga identificable la revisión capturada. Rehaga la evidencia afectada cuando cambien el renderizado, el diseño, el ajuste de texto, el recorte, las regiones de interacción, el texto de configuración regional, el foco, la interacción, el comportamiento responsivo u otra entrada sensible a la presentación. Una preocupación concreta del revisor sobre la presentación sigue requiriendo evidencia para esa preocupación.

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. En el caso de cambios visuales sensibles a la presentación, incluya o enlace las capturas de pantalla requeridas en dimensiones representativas de terminal o viewport, con suficiente contexto alrededor para poder juzgar el resultado. Registre las dimensiones numéricas solo cuando sean necesarias para reproducir o evaluar un problema concreto de presentación. Para un cambio renderizado de la interfaz que sea solo semántico y cumpla los requisitos, indique el HEAD exacto, la salida final de la interfaz compatible que se ejecutó, el estado modificado y el contenido visible observado. Para un cambio determinista de texto plano que cumpla los requisitos, incluya en su lugar la salida exacta de la interfaz compatible, la revisión probada y el contexto relevante del formateo de la salida. Enlace la comprobación automatizada o incluya el comando seguro exacto cuando ayude a que otro revisor pueda 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.