Tests et CI
Utilisez une configuration distincte pour les tests fonctionnels si vos outils de test risquent de déclencher les défenses avancées. Il n'existe ni point de terminaison de test ni environnement distinct dans le tableau de bord.
Pourquoi les tests ont besoin de leur propre build
Les défenses avancées (VM Self Defending, VM Debug Protection, VM Domain Lock et leurs équivalents de base selfDefending, debugProtection et domainLock) agissent aussi contre vos propres agents, outils d'automatisation et débogueurs. Elles peuvent arrêter l'exécution, lever des erreurs sans rapport ou produire des résultats incorrects. disableConsoleOutput remplace globalement les méthodes de console par des fonctions vides, pour chaque script de la page et pas seulement pour le script obfusqué : les assertions fondées sur les journaux ne voient donc rien. Exécutez les tests fonctionnels sur un build de test distinct où ces fonctionnalités sont désactivées.
Configuration des tests fonctionnels
Dérivez la configuration de test de vos réglages communs et appliquez ces surcharges après avoir sélectionné un préréglage. Elles désactivent les versions VM et de base de Self Defending, Debug Protection et Domain Lock, et désactivent disableConsoleOutput (les préréglages Low, Medium et High l'activent). Passez des valeurs explicites : omettre une option peut laisser un préréglage l'activer.
CI
Exécutez d'abord le code d'origine, puis soumettez le build de test obfusqué aux mêmes vérifications. Consignez l'entrée, les options effectives, la version de l'obfuscateur et les avertissements du build afin de pouvoir reproduire les échecs. Le tableau de bord et les réponses directes de l'API indiquent les avertissements et la version résolue ; le paquet javascript-obfuscator indique la version dans son message de progression, mais n'indique pas les avertissements.
Une fois les vérifications fonctionnelles réussies, générez un artefact de publication distinct à partir des réglages de production d'origine. Validez cet artefact précis dans son environnement d'exécution prévu, sur un domaine autorisé, sans outils d'automatisation ni débogueurs que ses défenses sont conçues pour détecter. La réussite du build de test ne valide pas la version protégée que vous publiez.
Les builds via le tableau de bord, le paquet javascript-obfuscator (CLI ou Node.js) et l'API utilisent les mêmes options de protection. Les tests via l'API utilisent les identifiants et le point de terminaison habituels, et les limites d'utilisation normales s'appliquent. En CI, placez les sorties de test et de production dans des chemins distincts et ne déployez que l'artefact de publication.
Si l'exécution échoue toujours, consultez Diagnostiquer les erreurs d'exécution de la VM.