Electron / Intermédiaire / 20 min de lecture
Comparaison de versions avec REA : qu’a changé la mise à jour ?
Comparez deux versions Electron avec REA. Retrouvez le changement de code responsable d’un problème, rejouez la même entrée et créez un test de non-régression ciblé.
Sur cette page
Un rapport de changements ciblé, avec l’identité des artefacts, les éléments du code et une vérification avant/après reproductible.
Il vous faudraLes deux versions d’une application que vous pouvez inspecter, leurs archives ASAR ou dossiers extraits, et REA 6.4.0.
01. Décrivez précisément la régression
« La mise à jour a cassé l’export » laisse trop de place aux suppositions. Notez l’entrée, l’action et la différence : par exemple, un titre contenant un guillemet s’exportait correctement avant la mise à jour et produit maintenant une ligne CSV mal formée.
Placez les deux versions dans des dossiers distincts. Notez leurs versions et les empreintes des artefacts. Comparez des éléments équivalents : une arborescence source de développement et un bundle minifié de production ne constituent pas le même type d’élément d’analyse.
npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/old/app.asar" --json > before.json
npx -y rea-agents@6.4.0 analyze-javascript-application "/absolute/path/new/app.asar" --json > after.json02. Comparez les résultats d’analyse conservés
Conservez les sorties JSON originales complètes. La procédure de comparaison attend les résultats d’analyse authentifiés de l’application ; un résumé modifié à la main ou une liste de noms de fichiers ne les remplace pas.
Demandez à votre agent connecté d’inspecter le schéma disponible de compare_application_versions et de fournir les deux résultats en conséquence. Cela évite de deviner des champs imbriqués susceptibles de changer entre versions. La CLI peut afficher le même contrat.
npx -y rea-agents@6.4.0 compare-application-versions --schemaUtilise compare_application_versions de REA avec les résultats d’analyse complets de before.json et after.json. Vérifie d’abord le schéma de l’outil installé. Centre le rapport sur l’export CSV : modules modifiés, chemins d’appels associés et correspondances non résolues. N’interprète pas l’absence d’un nœud dans une couverture partielle comme une preuve de suppression.03. Comparez la fonction, pas les noms minifiés
Partez du bouton, du canal IPC ou de la fonction de formatage déjà identifiés. Suivez cette fonction dans les deux versions et inspectez le code modifié. Les noms de variables minifiés changent souvent à la compilation sans modifier le comportement.
L’empreinte d’un module permet d’établir une identité exacte. Renommer une fonction ou renuméroter un fragment de bundle ne suffit pas à prouver un changement de sens. Gardez visibles dans le rapport les zones sans correspondance ou partiellement analysées.
- Les deux versions contiennent-elles le point d’entrée de la fonction ?
- Quelle zone du code diffère réellement ?
- La branche modifiée affecte-t-elle l’entrée qui échoue ?
- Le packaging, la configuration ou une couverture incomplète pourraient-ils expliquer la différence ?
04. Rejouez la même entrée dans les deux versions
Utilisez des dossiers de données temporaires distincts pour éviter que la nouvelle application ne migre l’état de test de l’ancienne. Exécutez exactement la même opération sur le même contenu. Conservez le fichier de sortie ou un relevé ciblé du comportement pour chaque exécution.
Pour une régression CSV, analysez les lignes produites et comparez les champs. Les différences d’octets, comme les fins de ligne, peuvent compter, mais un horodatage modifié ne doit pas masquer le véritable défaut de guillemets. Documentez toutes les normalisations utilisées.
Crée un test de non-régression pour l’entrée exacte observée. Compare les champs exportés après analyse des anciennes et nouvelles sorties. Montre les différences brutes et toute comparaison normalisée. Distingue le changement de code suspecté du comportement effectivement reproduit.05. Rédigez un rapport de bogue utile
Indiquez l’identité des deux versions, une entrée qui échoue, les étapes exactes de reproduction, les anciennes et nouvelles sorties observées et la plus petite différence de code pertinente. Précisez si le comportement a été reproduit ou seulement prédit à partir du code statique.
Une bonne comparaison débouche sur une action : un test de non-régression, un contournement de compatibilité ou un remplacement très ciblé. Ce tutoriel présente une méthode ; il ne signale pas de régression dans une version commerciale nommée.
Commandes vérifiées avec REA 6.4.0. Les résultats propres à une cible dépendent du fichier et du moteur utilisés. Lire la source du projet et le périmètre →
Vous découvrez l’outil ? Qu’est-ce que REA ? · Comment nous vérifions nos guides