Astuces pour tester des applications héritées riches en données

Question

Je travaille sur une application héritée très volumineuse et à forte intensité de données. Tant la base de code & amp; base de données sont massives en échelle. Une grande partie de la logique métier est répartie sur tous les niveaux, y compris les procédures stockées.

Quelqu'un a-t-il des suggestions sur la manière de commencer à appliquer "unité"? des tests (tests d'intégration techniques, car ils doivent tester plusieurs niveaux pour un seul aspect de presque tous les processus) dans l'application de manière efficace? L'architecture actuelle ne prend pas facilement en charge tout type d'injection ou de moquage. Un nouveau code est en cours d’écriture pour faciliter les tests, mais qu’en est-il du code hérité? En raison de la forte dépendance à l'égard des données et de la logique métier de la base de données, j'utilise actuellement SQL en ligne pour rechercher des données à utiliser pour les tests, mais elles prennent beaucoup de temps. La création de vues et / ou de procédures stockées ne suffira pas.

Quelles approches avez-vous adoptées (le cas échéant)? Qu'est-ce qui a fonctionné? Ce qui n'a pas & amp; Pourquoi? Toute suggestion serait appréciée. Merci.

Answer 1

Obtenez une copie de Fonctionnement efficace avec du code hérité par Michael Feathers. Il contient de nombreux conseils utiles pour travailler avec de grandes bases de code non testées.

Un autre bon livre est les Modèles de réingénierie orientés objet . La plupart du livre n'est pas spécifique aux logiciels orientés objet. Le texte intégral est disponible en téléchargement gratuit au format PDF.

De ma propre expérience: essayer de ...

• Automatiser la construction et le déploiement
• Obtenez le schéma de base de données dans le contrôle de version, s'il ne l'est pas encore. Habituellement, les bases de données incluent des données de référence dont le code transactionnel doit exister avant de pouvoir fonctionner. Obtenez ceci aussi sous contrôle de version. Des outils tels que dbdeploy peuvent vous aider à reconstruire facilement un schéma et des données de référence à partir d'une séquence de deltas.
• Installez une version de la base de données (et de tout autre service d'infrastructure) sur votre poste de travail de développement. Cela vous permettra de travailler sur la base de données sans avoir à passer continuellement par des DBA. C'est aussi plus rapide que d'utiliser un schéma sur un serveur partagé dans un centre de données distant. Tous les principaux serveurs de base de données commerciaux ont des versions de développement gratuites (comme dans Beer) qui fonctionnent sous Windows (si vous êtes bloqué dans la situation peu enviable de développer sous Windows et de déployer sous Unix).
• Avant de commencer à travailler sur une zone du code, écrivez des tests de bout en bout qui couvrent en gros le comportement de la zone sur laquelle vous travaillez. Un test de bout en bout doit exercer le système de l'extérieur - en contrôlant son interface utilisateur ou en interagissant via des services réseau - afin que vous n'ayez pas besoin de changer le code pour le mettre en place. Il agira comme un test de régression (imparfait) et vous donnera plus de confiance pour refactoriser les éléments internes du système vers une structure plus facile à tester.
• S'il existe des plans de tests manuels, lisez-les et voyez ce qui peut être automatisé. La plupart des plans de tests manuels sont presque entièrement rédigés dans un script, ce qui en fait des solutions faciles pour l'automatisation
• Une fois que vous avez une couverture complète des tests, reformulez le code en unités plus faiblement couplées à mesure que vous le modifiez et / ou l'étendez. Entourez ces unités avec des tests unitaires.

Choses à éviter:

• Copie des données de la base de production dans l'environnement que vous utilisez pour les tests automatisés. Cela rendra vos tests imprévisibles. Bien sûr, exécutez le système avec une copie des données de production, mais utilisez-le comme test exploratoire, pas comme test de régression.
• Annulation des transactions à la fin des tests pour les isoler les unes des autres. Cela ne testera pas le comportement qui ne se produit que lorsque les transactions sont validées et jettera des données précieuses pour diagnostiquer les échecs de test. Les tests doivent plutôt garantir que la base de données se trouve dans un état initial connu au démarrage.
• Création d'un "petit" " ensemble de données pour l'exécution de tests. Cela rend les tests difficiles à comprendre car ils ne peuvent pas être lus comme une seule unité. Le " minuscule " le jeu de données grandit rapidement à mesure que vous ajoutez des tests pour différents scénarios. Au lieu de cela, les tests peuvent insérer des données dans la base de données pour configurer le montage de test.

Answer 2

«Test de la modernisation des applications héritées», souligne:

1. Présentation générale de la création des tests dans AscentialTest

2. Méthodes de conversion des objets hérités vers la nouvelle plate-forme Composants de la définition d'objet

3. Comment s'assurer que la version modernisée de l'application produit les mêmes résultats

Pour plus de détails sur l'utilisation de l'application test héritée, veuillez vérifier ici:

http: // gestion des applications .cioreview.com / whitepaper / test-legacy-application-modernization-wid-529.html