Electron / Intermedio / 20 min de lectura

Comparación de versiones con REA: ¿qué cambió la actualización?

Compara dos versiones de Electron con REA. Encuentra el cambio de código que rompió un flujo de trabajo, repite la misma entrada y crea una prueba de regresión específica.

En esta página
Qué obtendrás

Un informe de cambios específico con identidades de artefactos, pruebas del código y una comprobación repetible del antes y el después.

Qué necesitas

Ambas versiones de una aplicación que puedas inspeccionar, sus archivos ASAR o carpetas extraídas y REA 6.4.0.

01. Precisar la regresión

«La actualización rompió la exportación» deja demasiado espacio a las conjeturas. Anota la entrada, la acción y la diferencia: por ejemplo, un título con una comilla se exportaba correctamente antes de actualizar y ahora produce una fila CSV mal formada.

Coloca ambas versiones de la aplicación en carpetas separadas. Registra sus etiquetas de versión y hashes de artefactos. Compara artefactos equivalentes: un árbol de código fuente de desarrollo y un paquete minificado de producción no son el mismo tipo de prueba.

Terminal
npx -y [email protected] analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y [email protected] analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json

02. Comparar las pruebas de análisis conservadas

Conserva las salidas JSON originales completas. El flujo de comparación requiere pruebas autenticadas de la aplicación; un resumen editado manualmente o una lista de nombres de archivos no las sustituye.

Pide a tu agente conectado que inspeccione el esquema disponible de compare_application_versions y proporcione ambos resultados según corresponda. Así evitas adivinar campos de entrada anidados que pueden cambiar entre versiones. La CLI puede mostrar el mismo contrato.

Terminal
npx -y [email protected] compare-application-versions --schema
Pídeselo a tu agente de programación
Usa compare_application_versions de REA con las pruebas completas de las aplicaciones en before.json y after.json. Comprueba primero el esquema de la herramienta instalada. Centra el informe en la exportación CSV: módulos modificados, rutas de llamadas relacionadas y correspondencias sin resolver. No interpretes la ausencia de un nodo en una cobertura parcial como prueba de eliminación.

03. Comparar la función, no los nombres minificados

Empieza por el botón, el canal IPC o el formateador que ya conoces. Sigue esa función en ambas versiones e inspecciona el código modificado. Los nombres de variables minificadas suelen cambiar durante una recompilación sin que cambie el comportamiento.

El resumen criptográfico de un módulo puede establecer una identidad exacta. Una función renombrada o un fragmento del paquete con numeración nueva no demuestra por sí solo un cambio semántico. Mantén visibles en el informe las regiones sin correspondencia o analizadas parcialmente.

  • ¿Contienen ambas versiones el punto de entrada de la función relevante?
  • ¿Qué región del código difiere realmente?
  • ¿Afecta la rama modificada a la entrada que falla?
  • ¿Podrían el empaquetado, la configuración o una falta de cobertura explicar la diferencia?

04. Repetir la misma entrada en ambas versiones

Usa carpetas de datos desechables separadas para que abrir la aplicación nueva no migre el estado de prueba de la versión anterior. Ejecuta exactamente la misma operación con el mismo contenido de prueba. Guarda el archivo de salida o un registro específico del comportamiento de cada ejecución.

Para una regresión de CSV, analiza las filas resultantes y compara los campos. Las diferencias de bytes, como los finales de línea, pueden importar, pero una marca de tiempo distinta no debe ocultar el fallo real de entrecomillado. Documenta todas las normalizaciones usadas en la comparación.

Pídeselo a tu agente de programación
Crea una prueba de regresión para la entrada exacta que observamos. Compara los campos exportados analizados de la salida anterior y la nueva. Muestra tanto la diferencia bruta como cualquier comparación normalizada. Mantén separado el cambio de código sospechoso del comportamiento realmente reproducido.

05. Escribir un informe de error útil

Incluye las identidades de ambas versiones, una entrada que falle, los pasos exactos de reproducción, las salidas observadas antes y después y la menor diferencia de código relevante. Indica si se reprodujo el comportamiento o si solo se predijo a partir del código estático.

Una buena comparación permite dar un siguiente paso: una prueba de regresión, una solución de compatibilidad o una sustitución de alcance limitado. Este tutorial es un flujo de trabajo; no afirma que exista una regresión en una versión comercial concreta.

Comandos comprobados con REA 6.4.0. Los resultados específicos dependen de tu artefacto y proveedor. Leer la fuente original y su alcance →

Seguir investigandoElegir tu próximo tutorial →

¿Acabas de conocer la herramienta? ¿Qué es REA? · Cómo revisamos nuestras guías