Comment testez-vous vos objets de gestion?

Question

Je souhaite implémenter des tests automatisés, en utilisant le framework de test Microsoft dans Visual Studio, pour mes projets de développement logiciel. J'ai créé quelques tests, et dans l'ensemble, c'est assez facile à utiliser.

Quels sont les meilleures pratiques des objets métier tests , plus particulièrement ceux qui lisent et écrivent à une base de données.

Est-il préférable de configurer une base de données de test distincte, à partir de la base de données de développement, où l'interface utilisateur est testée, et juste tester contre cette base de données? Fondamentalement, il suffit de le remplir avec des données indésirables.

Est-il préférable d'adopter un certain type de nettoyage après mentalité, ce qui signifie que si j'essaie la méthode AddUser, est-ce que j'ajoute l'utilisateur, vérifie mes tests, puis supprime l'utilisateur?

Testez-vous chacune des méthodes CRUD dans une seule méthode de test? Enfin, qu'en est-il des règles métier individuelles comme la vérification des chaînes de taille correcte, les dates de début sont inférieures aux dates de fin, CustomerId est un client correct et ainsi de suite. Je me rends compte que c'est une question assez large ... juste à la recherche d'une direction ... prendre des mesures de bébé.

Plus d'informations ...

Lot de bonnes réponses! Je ne suis pas sûr que je serais en mesure de retirer une base de données fictive. J'utilise l'AAPC comme cadre pour mes objets. Il faudrait un refactoring sérieux pour rendre cela testable avec des objets simulés. Je vais regarder ça. Bien que, à un moment donné, je veuille tester l'interaction de la base de données ... lors de l'utilisation d'une base de données fictive, où/quand testeriez-vous réellement la communication de la base de données?

Une autre question ... est-il préférable de garder chaque méthode de test non dépendante d'autres tests?

Answer 1

Idéalement, vous auriez des objets métier qui n'accèdent pas directement à la base de données, mais qui utilisent des objets auxiliaires ou un type de structure ORM (Object-Relational Mapping). Ensuite, vous pouvez tester vos BO sans base de données, en se moquant éventuellement de certains objets d'aide. C'est probablement le moyen le plus propre, car vous évitez la complexité d'une vraie base de données et ne faites vraiment que tester votre logique métier.

Si vous ne pouvez pas éviter de combiner les règles de gestion et l'accès à la base de données en une seule classe (probablement une conception problématique, mais parfois difficile à éviter), vous devez tester par rapport à une base de données.

La seule option raisonnable est d'avoir un DB distinct pour les tests automatiques. Vos méthodes de test doivent tout supprimer lors de l'installation lors de l'installation, puis charger toutes leurs données, faire le test et vérifier les résultats.

N'essayez même pas d'initialiser la base de données une seule fois, puis exécutez tous les tests sur les mêmes données. Un test va accidentellement changer les données, et d'autres tests échoueront mystérieusement. J'ai fait cela et je l'ai regretté ... Chaque test doit vraiment se tenir tout seul. Pour faire tout cela, je recommande fortement une sorte de cadre de test de base de données. Ils vous aident à nettoyer la base de données, à charger les données nécessaires et à comparer les résultats aux résultats attendus. J'utilise DBUnit (pour Java), mais il y en a beaucoup d'autres pour d'autres langages.

Answer 2

Généralement, je crée le BO, l'enregistre dans le db dans la configuration de l'appareil, puis j'ai des tests pour différents insert/update/selects puis dans mon teardown supprimer l'objet de la base de données. Cela permet de garder les choses bien et propres, surtout quand il y a beaucoup de contraintes, votre db de test peut devenir très rapide si vous ne supprimez pas tout ce que vous créez dans vos tests.

Answer 3

Je vous recommande d'implémenter vos objets métier afin qu'ils ne soient pas conscients de la base de données. Utilisez des méthodes sur la couche d'accès aux données qui peuvent enregistrer/récupérer correctement les objets métier en fonction de leur type (c'est-à-dire, elle a un mappage interne entre les tables et les objets auxquels elles correspondent). Lorsque vous testez votre objet métier lui-même, vous n'avez pas à vous soucier de la base de données. Créez simplement l'objet, utilisez peut-être la réflexion pour définir des champs privés et effectuez votre test sur l'objet. Lorsque vous testez du code qui doit interagir avec la couche d'accès aux données, utilisez la fonction de simulation pour créer une couche de données fantaisie et paramétrer les attentes pour renvoyer les objets souhaités ou répondre correctement aux sauvegardes. Vous devrez peut-être développer votre couche de données vers une interface (ou l'inclure dans une classe moqueuse si vous utilisez un cadre rigide qui ne prend pas en charge le moquettage directement). La plupart des frameworks moqueurs nécessitent que les méthodes soient virtuelles pour permettre la création d'une fausse implémentation. L'utilisation d'interfaces force les méthodes de la classe d'implémentation à être virtuelles, ce qui facilite grandement les moqueries.

Answer 4

Utilisez dependency injection. Implémentez vos méthodes de base de données dans une interface. Ensuite, écrivez une nouvelle implémentation de l'interface avec les données de contrôle pour tester les scénarios applicables.

Answer 5

Pour tester DB Access Layer, vous ne devez pas exécuter tous les tests sur la même base de données. Certains tests peuvent échouer car ils dépendent des résultats d'autres tests. Donc ce n'est pas ce que tu veux. En fait, après chaque test, vous devez rétablir l'état d'origine du db avant le test. Dans ma pratique, je conserve l'ensemble de données de test dans un fichier XML et avant chaque test, il configure les données en db en utilisant le XML. Donc, chaque test s'exécute sur un jeu de données.

Answer 6

Je suis d'avis que vous devriez tester vos objets métier avec une base de données moched. Dans certains cas, vous souhaiterez peut-être conserver vos données dans le cadre du test. Les inconvénients à cela sont des tests plus longs et le besoin de nettoyage.

Une solution à cela qui pourrait vous aider est d'utiliser une base de données en mémoire pour vos tests. SQLite par exemple vous permet de créer des bases de données en mémoire à la volée, et quand vous les avez éliminées, elles sont parties. Cela rend vos tests beaucoup plus rapides, et vous n'avez pas besoin de configurer de code de nettoyage - alors que vous pouvez réellement tester votre code SQL/db grâce à des tests automatisés.

Answer 7

(je sais que vous ne pas utiliser Java, mais la stratégie générale ci-dessous ne dépend pas de Java du tout)

Je travaille sur un projet Java qui utilise beaucoup de code EJB3/JPA. J'ai décidé de créer une sorte de conteneur bidon capable de "déployer" des EJB et d'utiliser une base de données en mémoire (HSQL) avec le gestionnaire d'entités hibernate.

Ce "conteneur" démarre en moins d'une seconde et me permet de tester la plupart des composants métier, y compris ceux qui accèdent à la base de données via JPA. Si un service est, par exemple, trop complexe à supporter, j'utilise simplement EasyMock (ou toute autre fausse bibliothèque) pour créer un faux service et le brancher sur le "conteneur".

Cela a été un énorme succès jusqu'à présent, mais il m'a fallu quelques jours pour mettre en œuvre l'infrastructure maquette.

Answer 8

Plus d'infos sur TDD avec CSLA peut être trouvé dans les réponses à this question. Surtout this one.

Egalement this question pourrait être intéressant.