2010-04-25 19 views
5

J'ai plusieurs fichiers avec code de test de code (qui utilise une classe "unittest").Comment organiser des tests d'intégrité des données en direct et des tests unitaires de code?

Plus tard, j'ai trouvé que ce serait bien de tester l'intégrité de la base de données aussi. Je mets ceci dans une arborescence de répertoires séparée. (Les choses comme les clés ont un format correct, les nœuds parents et enfants pointent correctement et tel.Edit: c'est un projet nosql, où je ne peux pas compter sur le contrôle de base de données vérifie l'intégrité référentielle et autres.)

J'utilise le même classe unittest pour les tests d'intégrité.

Maintenant, je me demande s'il est vraiment logique de garder cela séparé. Pour tester l'intégrité des données, je duplique souvent des parties du code que j'utilise pour tester le code qui gère les données.

Mais ce n'est pas la même chose. Les tests de code utilisent des bases de données de test (qui sont supprimées après chaque test) et les tests d'intégrité se connectent aux données en direct et les analysent. Les tests d'intégrité que je veux appeler à partir de cron et envoyer une alarme si quelque chose se passe dans la base de données en direct.

Comment géreriez-vous cela? Existe-t-il des normes pour une telle configuration? Quelle est votre expérience?

Ma tendance est de tout mettre dans le même fichier, ce qui entraînerait l'exécution des tests de code par le cron sur l'environnement de production. Ce qui me motive aussi, c'est d'essayer de garder le projet simple et de ne pas avoir trop de fichiers touchés par une seule tâche ou un flux de travail. Sans tous les tests, j'ai déjà un fichier de classe, une sous-classe, une classe liée, quelques fichiers de bibliothèque (helper) et le code principal. Le test ajoute un fichier. Cela m'aide à garder mon attention concentrée pendant le codage, c'est moins stressant et je crois que je fais moins d'erreurs, et je peux me souvenir plus rapidement et trouver une certaine partie du code avec moins de fichiers affectés. Un seul fichier de test par workflow aiderait ici. Si je le garde séparé il y a 2 fichiers (tests d'intégrité des données et tests de code) et peut-être 3 (une bibliothèque commune pour les deux). L'abstraction ajouterait de la complexité. Je suis en train de refactoriser un petit peu et de déplacer seulement les fichiers de test de données dans la même arborescence de répertoires où le test de code existe, mais en gardant des fichiers différents avec le nom "intégrité" ou "test". Je ne vais pas (encore) fusionner les fichiers, car 2 personnes ont déconseillé de le faire, et je crois en leur expérience et conseil pour le moment. Je vais vivre avec la duplication de code pour le moment.

Édition3: J'ai oublié de mentionner que la sélection des tests par cycle n'est pas déterminée par l'arborescence dans ce cas. Les tests sont énumérés dans un fichier maître, j'ai donc 2 fichiers maîtres "intégrité" et "test de code" pour le moment, et le test peut vivre dans la même structure de directure.

Peut-être que plus de gens répondront. Merci pour votre contribution précieuse, qui m'aide déjà à développer la structure finale!

Éditer4: J'ai fait plus de refactoring maintenant. Il semble que je devrais garder 2 fichiers, mais avec un but légèrement modifié. Un ciblé pour la surveillance planifiée sur le serveur de production. Et un autre pour le développement. Mais dans les deux fichiers peuvent être des tests d'intégrité ou de code. Et dans les deux fichiers, les opérations peuvent être effectuées sur des bases de données de test (effacées après le test) et sur la base de données permanente (chacune possède une base de données permanente, un serveur de production et un serveur de développement). Et une chose importante: je me trouve déplacer beaucoup de code commun à partir des fichiers de test dans les fichiers de classe. Ainsi, les classes obtiennent également des capacités qui ne sont que pour les tests.J'aime ça jusqu'ici, je me sens propre. Je ne suis pas (encore) en train de créer une bibliothèque pour les tests partagés entre les deux interfaces de test, ce code est passé au fichier de classe de l'obejct qui est en cours de création.

Veuillez noter que mes commentaires ci-dessous sont signés avec "user89021" mais c'est moi, karlthorwald. Je ne peux rien y faire.

Répondre

4

Vous devez séparer la base de données de tests liés à partir des tests unitaires « purs ». Le coût d'avoir deux assemblages différents est très faible compte tenu des avantages - vous disposez d'une suite de tests rapides, sans environnement, que vous pouvez exécuter sur n'importe quelle machine et une suite plus lente qui teste l'intégrité de la base de données. endroits (par exemple le serveur de construction).

Un autre avantage est que vous pouvez avoir deux processus de construction (rapide et nocturne) qui exécutent différentes suites de tests.

Pour éviter la duplication de code, vous pouvez créer un autre ensemble avec les méthodes/actions communes dont les deux suites de tests ont besoin. Ne vous inquiétez pas trop de la duplication des tests réels car vous testez différentes choses (soit la logique ou la base de données), donc tôt ou tard vos tests deviendront très différents selon ce que vous essayez de tester.

4

Votre approche pour les séparer est bonne. Vos préoccupations concernant la duplication de code sont valides à 100%.

La solution est assez droite - abstraction abstraite fonctionnalité commune entre les tests - par ex. "RunTest", "AnalyzeResult", "ConnectToDB" - dans une bibliothèque commune (vous ne spécifiez pas quelle langue mais je suppose qu'il a un concept de bibliothèque) qui peut être transmis des détails de configuration tels que la base de données à laquelle se connecter. Utilisez ensuite cette bibliothèque indépendamment du pilote de test unitaire et du pilote de test d'intégrité - ce qui, si vous êtes qualifié/chanceux, peut avoir très peu de code autre que la configuration (par exemple, quelle base de données vous connecter, comment rapport des résultats, et quels tests exécuter).

De même, le cas échéant, les entrées communes/jeux de données peuvent être placés dans le répertoire commun

+0

Merci. Je ne spécifie pas parce que je veux éviter que ma question soit taguée avec les langues. Bibliothèques, objets, héritage, tout ce qui est possible ici. – user89021

+0

Ce n'était pas facile d'accepter une réponse parce qu'ils sont tous les deux très bons et m'ont aidé. Merci beaucoup. – user89021

0

Encore une réponse. Vous avez deux types de tests. Ce que je voudrais faire, c'est aborder les tests d'intégrité. Ce que vous pouvez vouloir faire est d'inclure les tests d'intégrité en fonction du code de production. IOW, avoir l'intégrité dans le cadre du système.

Vous avez déjà mentionné que la duplication est un problème et que vous êtes en train de refactoriser pour supprimer la duplication. Le code refactorisé a bien sûr des tests de développement?

La surveillance du système peut être un code de production. Donc, quel que soit le code que vous écrivez devient partie intégrante du système.

La bonne chose à ce sujet est que vous développez votre code à travers vos tests de développement.

+0

Merci. Votre réponse m'a vraiment aidé, en particulier "la surveillance du système peut faire partie de la production". Mon développement s'est beaucoup amélioré avec ces 3 réponses! – user89021