Je suis nouveau sur TDD et je trouve que RegExp est un cas bien particulier. Existe-t-il un moyen spécial de les tester, ou puis-je simplement les menacer en tant que fonctions régulières?
Réponses
Trop de publicités?Vous devriez toujours tester votre regexen, comme n'importe quelle autre partie du code. Ils sont au plus simple une fonction qui prend une chaîne de caractères et renvoie un booléen, ou retourne un tableau de valeurs.
Ici sont quelques suggestions sur ce qu'il faut penser quand il s'agit de concevoir des tests unitaires pour regexen. Ce ne sont pas pas dur et rapide des prescriptions pour le test de l'unité de conception, mais quelques lignes directrices à la forme de votre pensée. Comme toujours, peser les besoins de votre test versus coût de la non-équilibrée avec le temps nécessaire pour mettre en œuvre toutes. (Je trouve que "d'exécution" le test est la partie la plus facile! :-] )
Points à considérer:
- Penser à chaque groupe (les parenthèses) comme une accolade.
- Pensez à tous | comme une condition. Assurez-vous de tester pour chaque branche.
- Penser à chaque modificateur (*, +, ? ) comme un chemin différent.
- (note: rappelez-vous la différence entre *, +, ? et *?, +?, et ??.)
- pour \d, \s, \w, et leurs négations, donner plusieurs dans chaque gamme de l'essayer.
- * Et +, vous avez besoin de tester pour le "non-valeur", " one " et "un ou plusieurs" pour chaque.
- Pour le rôle de "contrôle" des personnages (par exemple, des chaînes dans la regex vous recherchez) test pour voir ce qui se passe si elles se présentent dans les mauvais endroits. Cela peut vous surprendre.
- Si vous avez des données du monde réel, utiliser autant que vous le pouvez.
- Si vous ne le faites pas, assurez-vous de tester à la fois les formes, simple et complexe qui doit être valide.
- Assurez-vous de tester ce que les regex caractères de contrôle n'lorsqu'il est inséré.
- Assurez-vous de vérifier que la chaîne vide est bien acceptées/rejetées.
- Assurez-vous de vérifier qu'une chaîne de chacun des différents types de caractères d'espacement sont bien acceptées ou rejetées.
- Assurez-vous que la bonne affaire de l'insensibilité est fait (l'indicateur i). Cela a peu me plus de fois que n'importe quoi d'autre dans le texte d'analyse (autres que des espaces).
- Si vous avez le x, m ou s options, assurez-vous de comprendre ce qu'ils font et de test (le comportement peut être différent)
Pour une regex qui renvoie les listes, aussi n'oubliez pas:
- Vérifier que les données que vous attendez est retourné, dans le bon ordre, dans les champs correspondants.
- Vérifiez que de légères modifications de ne pas retourner le bon de données.
- Vérifier que le mélange anonyme des groupes et des groupes nommés analyser correctement (par exemple,
(?<name> thing1 ( thing2) )
) - ce comportement peut être différent basé sur le moteur d'expressions régulières que vous utilisez. - Une fois de plus, donner beaucoup de monde réel essais.
Si vous utilisez des fonctionnalités avancées, telles que la non-retour en arrière groupes, assurez-vous de comprendre complètement le fonctionnement de cette fonctionnalité, et en utilisant les lignes directrices ci-dessus, la création de l'exemple des chaînes de caractères qui doivent travailler pour et le contre de chacun d'eux.
Selon votre bibliothèque regex mise en œuvre, la façon dont les groupes sont capturées peuvent être différentes. Perl 5 a une "ouvrir la parenthèse de" l'ordre de la commande, C# a que partiellement, sauf pour les groupes nommés et ainsi de suite. Assurez-vous d'expérimenter avec votre saveur de savoir exactement ce qu'il fait.
Ensuite, intégrer directement dans vos autres tests unitaires, soit dans leur propre module de ou en relation avec le module qui contient les regex. Pour particulièrement désagréable regexen, vous pouvez trouver vous avez besoin de beaucoup, beaucoup de tests pour vérifier que le modèle et toutes les fonctionnalités que vous utilisez sont corrects. Si la regex est un grand (ou presque tous) de l'œuvre que la méthode est en train de faire, je vais utiliser les conseils ci-dessus à la mode entrées pour tester cette fonction et pas la regex directement. De cette façon, si plus tard vous décidez que la regex n'est pas la voie à suivre, ou si vous voulez le décomposer, vous pouvez capturer le comportement de l'expression régulière fournie sans changer l'interface - c'est à dire, la méthode qui appelle la regex.
Aussi longtemps que vous savez vraiment comment une regex fonctionnalité est censé travailler, dans votre saveur de regex, vous devriez être en mesure de créer des emplois décents cas de test. Juste assurez-vous que vous avez vraiment, vraiment, vraiment comprendre le fonctionnement de cette fonctionnalité!
Il suffit de jeter un tas de valeurs à elle, pour vérifier que vous obtenez le bon résultat (match/non-match ou un particulier, la valeur de remplacement, etc).
Surtout, s'il y a des cas particuliers qui vous me demande si ils vont travailler ou pas, les saisir dans une unité de test et de l'expliquer dans un commentaire pourquoi ils travaillent. De cette façon, quelqu'un qui veut changer le regex sera en mesure de vérifier que le cas de coin fonctionne encore, et il vous donnera un indice sur la façon de le réparer en cas de casse.
Vraisemblablement, vos expressions régulières sont contenues dans une méthode d'une classe. Par exemple:
public bool ValidateEmailAddress( string emailAddr )
{
// Validate the email address using regular expression.
return RegExProvider.Match( this.ValidEmailRegEx, emailAddr );
}
Vous pouvez maintenant écrire des tests pour cette méthode. Je suppose que le fait est que la regex est un détail d'implémentation - votre test doit tester l'interface, qui dans ce cas n'est que la méthode de validation de l'e-mail.
Je créerais un ensemble de valeurs d'entrée avec les valeurs de sortie attendues, un peu comme tous les autres cas de test.
De plus, je peux recommander à fond le logiciel gratuit Regex Tool Expresso . C'est un fantastique éditeur / débogueur de regex qui m'a épargné des jours de douleur par le passé.