Comment testez-vous les applications d'entreprise à l'unité?

Question

Comment les gens testent-ils leurs applications métier? J'ai vu beaucoup d'exemples de tests unitaires avec des exemples "simples à tester". Ex. une calculatrice. Comment les unités testent-elles les applications lourdes en données? Comment préparez-vous vos données d'échantillon? Dans de nombreux cas, les données d'un test peuvent ne pas fonctionner du tout pour un autre test, ce qui rend difficile de disposer d'une base de données de test unique. Le test de la partie d'accès aux données du code est assez simple. Il teste toutes les méthodes qui fonctionnent contre les données qui semblent difficiles à tester. Par exemple, imaginez un processus d'affectation où l'accès aux données est important pour déterminer ce qui est affiché, les nombres sont ajustés, etc. Il y a un certain nombre d'étapes intermédiaires qui doivent être testées et vérifiées par la suite. réussi. Certaines de ces étapes peuvent en fait être des procédures stockées.

Dans le passé, j'ai essayé d'insérer les données de test dans une base de données de test, puis d'exécuter le test, mais honnêtement, il est assez pénible d'écrire ce type de code (et sujet aux erreurs). J'ai également essayé de créer une base de données de test à l'avance et d'annuler les modifications. Cela fonctionne bien, mais dans un certain nombre d'endroits, vous ne pouvez pas le faire facilement (et beaucoup de gens diraient que c'est un test d'intégration, donc, je dois encore pouvoir le tester d'une manière ou d'une autre).

Si la réponse est qu'il n'y a pas une bonne façon de gérer cela et que c'est juste une sorte de suce, ça serait utile de le savoir aussi.

Toutes pensées, idées, suggestions ou conseils sont appréciés.

Answer 1

Je dois appuyer le commentaire de @Phil Bennett alors que j'essaie d'aborder ces tests d'intégration avec une solution de restauration.

J'ai un poste très détaillé sur l'intégration de tester votre accès aux données couche here

Je montre non seulement l'échantillon classe d'accès aux données, classe de base, et l'échantillon classe de fixation de transaction DB, mais un test d'intégration CRUD complète w/données d'échantillon montrées. Avec cette approche, vous n'avez pas besoin de plusieurs bases de données de test car vous pouvez contrôler les données qui entrent dans chaque test et une fois le test terminé, toutes les transactions sont annulées afin que votre base de données soit propre. Concernant les tests unitaires de la logique métier de votre application, j'appuie également les commentaires de @Phil et @Mark car si vous moquez toutes les dépendances de votre objet métier, il devient très simple de tester votre logique d'application. un temps;)

Edit: Alors vous êtes à la recherche d'un énorme test d'intégration qui va tout vérifier à partir de la base de pré-base logique/procédure stockée avec logique et enfin une vérification sur le chemin du retour? Si oui, vous pourriez casser ceci en 2 étapes:

• 1 - test de l'unité de la logique qui se produit avant que les données est poussé dans votre code d'accès aux données. Pour exemple, si vous avez un code qui calcule quelques chiffres sur la base certaines propriétés - écrire un test qui vérifie que pour voir si la logique de cette 1 fonction fait ce que vous avez demandé à faire. Mock hors toute dépendance sur la classe d'accès aux données de sorte que vous pouvez l'ignorer pour ce test de la logique d'application seul.

• 2 - Test d'intégration de la logique qui se produit une fois que vous prenez vos données manipulées (à partir de la méthode précédente unité que nous avons testé) et appelez la procédure appropriée stockée. Faites cela à l'intérieur d'une classe de test spécifique aux données afin que vous puissiez annuler après terminé.Après votre procédure stockée a été exécuté, faire une requête contre la base de données pour obtenir votre objet maintenant que nous avons fait une certaine logique contre les données et vérifier a les valeurs que vous attendiez (logique de la procédure post-stockée/etc)

Si vous avez besoin d'une entrée dans la base de données pour la procédure stockée à exécuter, il suffit d'insérer les données avant d'exécuter la procédure stockée qui a votre logique à l'intérieur. Par exemple, si vous devez tester un produit, vous devrez peut-être insérer une entrée de fournisseur et de catégorie. Avant d'insérer votre produit, faites un encart rapide et sale pour un fournisseur et une catégorie afin que votre insertion fonctionne comme prévu.

Answer 2

Pour beaucoup de différentes pistes au cours de la même logique mais avec des données différentes que vous pouvez utiliser CSV, autant de colonnes que vous le souhaitez pour l'entrée et la dernière pour la sortie, etc.

Answer 3

Cela dépend de ce que vous êtes essai. Si vous testez un composant de logique applicative, son importance provient de l'origine des données et vous utiliserez probablement une maquette ou une classe de talon roulée à la main qui simule la routine d'accès aux données que le composant aurait appelée dans la nature. La seule fois où je salis l'accès aux données, c'est quand je teste les composants d'accès aux données eux-mêmes. Même alors, j'ai tendance à ouvrir une transaction DB dans la méthode TestFixtureSetUp (cela dépend évidemment du framework de test que vous utilisez) et à annuler la transaction à la fin de la suite de tests TestFixtureTeardown.

Answer 4

Il semble que vous pourriez tester des systèmes basés sur des messages, ou des systèmes avec des interfaces hautement paramétrées, où il y a un grand nombre de permutations de données d'entrée.

En général, toutes les règles de test standard unti tiennent encore:

• Essayez de faire les unités testées en tant que petit et discret que possible.
• Essayez de rendre les tests indépendants.
• Code factor pour découpler les dépendances.
• Utilisez des simulacres et des talons pour remplacer les dépendances (comme DATAACCESS)

Une fois cela fait, vous avez supprimé beaucoup de la complexité des tests révélant l'espérons de bonnes séries de tests unitaires, et en simplifiant les données d'échantillon .

Une bonne méthodologie pour ensuite compiler des données d'échantillon pour le test qui nécessitent encore des données d'entrée complexes est Orthogonal testing ou voir here.

J'ai utilisé ce type de méthode pour générer des plans de test pour les solutions WCF et BizTalk où les permutations de messages d'entrée peuvent créer plusieurs chemins d'exécution possibles.

Answer 5

Les cadres de simulation vous permettent de tester vos objets métier. Les tests pilotés par les données finissent souvent par devenir plus un test d'intégration qu'un test unitaire. Ils supportent également la gestion de l'état d'un magasin de données avant et après l'exécution du test et le temps de connexion et d'exécution.

En général, j'éviterais de faire des tests unitaires qui touchent la base de données à partir de vos objets métier. Quant à tester votre base de données, vous avez besoin d'un stratergy différent. Cela étant dit, vous ne pouvez jamais totalement échapper aux tests pilotés par les données, ce qui ne fait que limiter le nombre de tests qui doivent réellement appeler vos systèmes dorsaux.

Answer 6

Mes tests fonctionnels automatisés suivent généralement l'un des deux crépite:

• Base de données Tests connectés
• Mock persistance Tests de la couche

Base de données Connected Tests

Quand j'ai automatisé tests qui sont connectés à la base de données, je fais généralement un seul modèle de base de données de test qui a assez de données pour tous les tests. Lorsque les tests automatisés sont exécutés, une nouvelle base de données de test est générée à partir du modèle pour chaque test. La base de données de test doit être constamment régénérée car le test modifie souvent les données. À mesure que des tests sont ajoutés, j'ajoute généralement plus de données au modèle de base de données de test.

Cette méthode de test présente de nombreux avantages. L'avantage évident est que les tests exercent également votre schéma. Un autre avantage est qu'après la mise en place des tests initiaux, la plupart des nouveaux tests seront en mesure de réutiliser les données de test existantes. Cela facilite l'ajout de tests supplémentaires. L'inconvénient est que la base de données de test deviendra difficile à manoeuvrer. Parce que les données seront généralement ajoutées un test à la fois, il sera incohérent et peut-être même irréaliste. Vous finirez aussi par maudire la personne qui a configuré la base de données de test en cas de modification importante du schéma de base de données (ce qui signifie généralement que je finis par me maudire).

Ce style de test ne fonctionne évidemment pas si vous ne pouvez pas générer de nouvelles bases de test à volonté.

Mock persistance Tests de la couche

Pour ce modèle, vous créez mock objects qui vivent avec les cas de test. Ces objets fantaisie intercepter les appels à la base de données afin que vous puissiez par programme fournir les résultats appropriés. Fondamentalement, lorsque le code que vous testez appelle la méthode findCustomerByName(), votre objet maquette est appelé à la place de la couche de persistance. La bonne chose à propos de l'utilisation des tests d'objets simulés est que vous pouvez obtenir très spécifique. Souvent, il existe des chemins d'exécution que vous ne pouvez pas atteindre dans des tests automatisés sans objets fantaisie. Ils vous permettent également de conserver un grand ensemble de données de test monolithique.

Un autre avantage est l'absence de dépendances externes. Comme les objets simulés simulent la couche de persistance, vos tests ne dépendent plus de la base de données. C'est souvent le facteur décisif lors du choix du motif à choisir. Les objets simulés semblent avoir plus d'impact lorsqu'ils traitent avec des systèmes de bases de données ou des bases de données héritées avec des termes de licence stricts.L'inconvénient des objets fantaisie est qu'ils entraînent souvent beaucoup de code de test supplémentaire. Ce n'est pas horrible parce que presque n'importe quel montant de code de test est bon marché lorsqu'il est amorti sur le nombre de fois que vous exécutez le test, mais il peut être ennuyeux d'avoir plus de code de test que de code de production.