Tester une regex, c’est aussi tester les refus attendus
Trouver une correspondance est un début, pas la preuve que le motif traduit votre intention. Un bon test comprend des textes presque corrects qui doivent être refusés.
Exprimer d’abord la règle en mots
Cherchez-vous un code dans un paragraphe ou validez-vous toute une ligne ? Trouver un fragment plausible dans une entrée invalide peut sembler réussi sans remplir le besoin.
Utilisez de petits exemples de caractères, longueurs et frontières. Un long texte masque les causes ; le motif n’applique pas les règles métier que vous n’avez pas écrites.
Les options et les écritures influencent le résultat
g demande plusieurs correspondances ; i modifie le traitement de la casse. En JavaScript, \w ne définit pas les mots de toutes les écritures ; des propriétés Unicode avec u peuvent être nécessaires.
ToolRoof teste la syntaxe JavaScript avec g, i, m, s, u. Les positions sont des unités UTF-16, pas toujours des symboles visibles. Ne supposez pas un comportement identique dans un autre moteur.
Références: MDN — JavaScript regular expressions, flags and Unicode
Des exemples réussis ne certifient pas la sécurité
Ajoutez un cas sans correspondance et les limites minimale et maximale voulues. Vérifiez aussi plusieurs lignes si cela correspond à l’usage.
Le traitement est borné et affiche au plus 200 correspondances ; atteindre ce plafond ne prouve pas leur épuisement. L’outil ne garantit pas rapidité ou sécurité pour toute entrée et n’exécute ni code de remplacement ni texte saisi.
Exemple : 2 codes acceptés, 2 cas proches refusés
Dans ID-17 ID-204 ID-7 XID-99, le motif \bID-\d{2,3}\b avec g trouve ID-17 et ID-204. ID-7 est trop court ; la frontière de mot empêche de commencer dans XID-99.
Sans g, seule la première correspondance revient. Cette règle décrit les codes de l’exemple ; elle ne prouve ni leur existence réelle, ni un droit d’accès, ni d’autres exigences du système.