Traducción automática

Esta página fue traducida automáticamente por IA y puede contener errores. Si algo no está claro, consulte la fuente en inglés.

Fuente en inglés · Reportar un problema de traducción

Arquitectura de pruebas

El sistema de pruebas de pplx_export es completamente offline, utiliza datos simulados verificados y bloquea el comportamiento del renderizador mediante instantáneas. Esta página describe la arquitectura y las garantías; la lista actual de módulos pertenece a Testing, y los detalles de los fixtures pertenecen a Test fixtures.

La sección mantiene su numeración de la visión general de la arquitectura.

---

1. Sistema de pruebas

Ejecute el conjunto con uv run pytest tests. Los recuentos de pruebas se informan desde la ejecución actual, no se tratan como una constante arquitectónica.

1.1 Capas

Capa	Módulos representativos	Contrato
Comportamiento de unidad pura	test_units.py, pruebas de credenciales/cookies/configuración	aislar funciones, clases, validación y normalización con entradas simuladas
Semántica de componentes	pruebas de interrupción, flujo de trabajo stub, variante de respuesta y relaciones	ejercitar la cooperación entre el analizador, el renderizador, el estado y el código de índice sin acceso a la red
Comportamiento de comando/estado offline	pruebas de relleno, sincronización de eliminación, inicialización y regresiones de revisión	ejecutar rutas de comando contra directorios temporales y transportes falsos
Instantáneas de renderizado	test_render_snapshots.py	pasar JSON con forma de API simulada a través de la ruta de re-renderizado de producción y comparar todos los bytes de Markdown con los golden confirmados

Los identificadores de revisión como N, V3, V4 y V5 son metadatos de trazabilidad a través de estas capas. No definen una arquitectura de tiempo de ejecución separada, y su relación con los módulos de prueba no es necesariamente uno a uno.

1.2 Flujo de datos de instantáneas

1. Un fixture simulado proporciona raw_entries.json, raw_blocks.json opcional y thread.json.
2. tests/conftest.py::render_fixture copia esos archivos en tmp_path.
3. El fixture llama a commands.rerender_cmd.rerender, la ruta de reconstrucción offline de producción.
4. Los archivos nuevos de conversation.md y turns/turn_*.md se comparan byte por byte con los productos golden confirmados golden/.

Los golden son expectativas generadas, no una fuente de datos independiente. Cualquier cambio en el renderizador que altere los bytes del artefacto hará que el conjunto de instantáneas falle hasta que se revise el cambio y los golden se regeneren intencionalmente.

1.3 Límites de aislamiento y confianza

• Origen del fixture — todas las entradas de fixture confirmadas son datos simulados. No se copian de cuentas reales, respuestas de API reales, web_archive/ o archivos privados.
• Límite de red — las pruebas utilizan rutas falsas y offline; los fixtures confirmados no requieren credenciales ni acceso a la red.
• Límite de configuración — el fixture de uso automático instala una configuración de cuenta de marcador de posición, por lo que el ~/.config real de un desarrollador no determina los resultados.
• Límite del sistema de archivos — el comportamiento de comandos y migraciones se ejecuta bajo tmp_path; los archivos de usuario no son objetivos de prueba.
• Límite de residuos — tests/scrub_fixtures.py --check rechaza cadenas específicas del entorno configuradas, rutas absolutas locales y credenciales de URL firmadas sin modificar archivos.

En conjunto, las aserciones de unidad, la semántica de componentes, las pruebas de estado de comando y las instantáneas a nivel de byte protegen tanto la lógica local como el contrato de re-renderizado de extremo a extremo.