Conseils pour tester une application héritée de données intensives

Question

Je travaille sur une très grande application héritée nécessitant beaucoup de données. Les deux base de données de base de code & sont massives dans l'échelle. Une grande partie de la logique métier est répartie sur tous les niveaux, y compris dans les procédures stockées. Est-ce que quelqu'un a des suggestions sur la façon de commencer à appliquer des tests «unitaires» (techniquement des tests d'intégration parce qu'ils doivent tester à travers les niveaux pour un seul aspect de presque n'importe quel processus donné) dans l'application de manière efficace? L'architecture actuelle ne supporte pas facilement n'importe quel type d'injection ou de moquerie. Un nouveau code est en cours de rédaction pour faciliter les tests, mais qu'en est-il du code existant? En raison de la forte dépendance vis-à-vis des données et de la logique métier de la base de données, j'utilise actuellement inline sql pour trouver des données à utiliser pour les tests, mais cela prend du temps. Créer des vues et/ou des procédures stockées ne suffira pas.

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

Answer 1

Obtenez une copie de Working Effectively with Legacy Code par Michael Feathers. Il est plein de conseils utiles pour travailler avec de grandes bases de code non testées.

Un autre bon livre est Object Oriented Reengineering Patterns. La plupart du livre n'est pas spécifique aux logiciels orientés objet. Le texte intégral peut être téléchargé gratuitement en format PDF.

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

• Automatiser la construction et le déploiement
• Obtenir le schéma de base de données dans le contrôle de version, si elle est pas encore. Généralement, 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 le contrôle de version. Des outils tels que dbdeploy peuvent vous aider à reconstruire facilement un schéma et à référencer des données à 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 les 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 bases de données commerciaux ont des versions de développement gratuites (comme dans la bière) qui fonctionnent sur Windows (si vous êtes coincé dans la situation peu enviable de développement sur Windows et de déploiement sur Unix). Avant de commencer à travailler sur une zone du code, écrivez des tests de bout en bout qui couvrent approximativement le comportement de la zone sur laquelle vous travaillez. Un test de bout en bout devrait exercer le système de l'extérieur - en contrôlant son interface utilisateur ou en interagissant via les services réseau - de sorte que vous n'aurez 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 internes du système vers une structure plus facile à tester.
• S'il existe des plans de test manuels, lisez-les et voyez ce qui peut être automatisé.
• Une fois que vous avez une couverture de tests de bout en bout, refactorisez le code en unités plus faiblement couplées lorsque 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 données 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 contre une copie des données de production, mais utilisez-le pour les tests exploratoires, pas pour les tests de régression.
• Annulation des transactions à la fin des tests pour isoler les tests les uns des autres. Cela ne testera pas le comportement qui ne se produit que lorsque les transactions sont validées et jettera des données utiles pour diagnostiquer les échecs de test. Au lieu de cela, les tests doivent s'assurer que la base de données est dans un état initial connu au démarrage.
• Création d'un jeu de données "minuscule" pour les tests à exécuter. Cela rend les tests difficiles à comprendre car ils ne peuvent pas être lus comme une seule unité. Le jeu de données «minuscule» devient rapidement très important lorsque 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 test-fixture.

Answer 2

« Test Héritage modernisation des applications », Faits saillants:

1. Vue d'ensemble de haut niveau de la façon dont les tests sont créés dans AscentialTest

2. façons de convertir l'héritage d'objets à la nouvelle plate-forme des composants de l'objet définition

3. Comment faire en sorte que la version modernisée de l'application produise les mêmes résultats

Pour plus de détails sur l'utilisation des applications existantes de test, ne vérifie ici:

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html