Tests et CI
Utilisez une configuration distincte pour les tests fonctionnels si vos outils risquent de déclencher les défenses d’exécution. Il n’existe ni endpoint de test ni environnement distinct dans le tableau de bord.
Configuration des tests fonctionnels
Dérivez la configuration de test de vos réglages communs et appliquez ces remplacements après le choix du préréglage. Ils désactivent Self Defending, Debug Protection et Domain Lock pour la VM et l’obfuscation classique. Fournissez des valeurs explicites : omettre une option peut laisser un préréglage l’activer.
CI
Exécutez d’abord le code original, puis le build de test obfusqué avec les mêmes contrôles. Conservez l’entrée, les options effectives, la version de l’obfuscateur et les avertissements pour reproduire les échecs.
Après la réussite des tests fonctionnels, générez un artefact de production distinct à partir des réglages d’origine. Validez cet artefact exact dans son environnement prévu, sur un domaine autorisé, sans automatisation ni débogueur 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.
L’interface, la CLI et l’API utilisent les mêmes options de protection. Les tests API utilisent les identifiants et l’endpoint habituels, avec les limites normales. En CI, séparez les sorties de test et de production et déployez uniquement l’artefact de production.
Si l’exécution échoue encore, consultez Diagnostiquer les erreurs d'exécution de la VM.