Existe-t-il une approche pratique pour utiliser le développement basé sur des tests dans une application COBOL?
est-ce que quelqu'un a trouvé des approches pratiques pour mettre en oeuvre le développement basé sur les tests (et potentiellement le développement basé sur le comportement) dans/pour les applications COBOL?
une solution idéale permettrait de tester à la fois l'unité et l'intégration du cobol en mode transactionnel (CICS) et en mode discontinu, assis au sommet de la combinaison habituelle de bases de données DB2 et de divers ensembles de données à Largeur fixe.
j'ai vu http://sites.google.com/site/cobolunit/, et il semble intéressant. Quelqu'un a vu ce travail dans la colère? Fait-il? Quels ont été les pièges?
Juste pour obtenir votre créativité, certaines "exigences" pour une approche idéale:
- permettre un test d'intégration pour exercer un programme cobol entier.
- permettre aux tests de certifier eux-mêmes leurs résultats (c.-à-d. faire des assertions à la xUnit)
- prise en charge du mode par lots et du SCIC COBOL.
- Devrait permettre à un test unitaire d'exercer des paragraphes individuels à l'intérieur d'un programme cobol en manipulant le stockage de travail avant/après l'invocation du code à l'essai.
- Devrait permet d'exécuter automatiquement une série de tests (suite) et de rendre compte du résultat global.
- Devrait supporter l'utilisation de fixtures de données de test qui sont configurées avant un test et démontées ensuite.
- Devrait test bien séparé du code de production.
- Devrait offrir un ratio test / code de production typique d'environ 1:1 (c.-à-d. que les tests d'écriture ne devraient pas multiplier la quantité de code écrit par tellement que le coût global de l'entretien augmente au lieu de baisser)
- ne Devrait pas exigent des développeurs COBOL d'apprendre un autre langage de programmation, À moins que cela ne soit en conflit direct avec ce qui précède exigence.
- rapports sur la couverture du code de soutien.
- encourager l'adoption de modèles de conception différents dans le code lui-même afin de le rendre plus facile à tester.
Commentaires bienvenue sur la validité/pertinence des exigences ci-dessus.
juste un rappel que ce que je cherche ici est de bons conseils pratiques sur la meilleure façon d'atteindre ce genre de choses - je ne suis pas s'attendre nécessairement à une solution préemballée. Je serais heureux d'avoir un exemple où quelqu'un a utilisé avec succès TDD dans cobol, ainsi que quelques conseils et gotchas sur ce qui fonctionne et ce qui ne fonctionne pas.
3 réponses
Peut-être découvrez QA Hiperstation. Pourrait coûter beaucoup cependant (comme tous les autres produits de mainframe).
utilisé seulement brièvement il y a longtemps donc ne peut pas prétendre être un expert. Je l'ai utilisé pour exécuter et vérifier une batterie de tests de régression dans un environnement de type COBOL/CICS/DB2/MQ-SERIES et je l'ai trouvé très efficace et flexible.
je dirais que cela pourrait être une des pièces de votre puzzle, mais certainement pas toute la chose.
quelle que soit la façon dont vous construisez/exécutez les tests unitaires, vous avez probablement besoin d'un résumé de la façon dont les tests se déroulent et à quel point le logiciel résultant est bien testé.
voir notre SD COBOL Test Coverage tool, spécialement conçu pour IBM COBOL.
cette réponse n'est peut-être pas aussi facile que vous (et moi) l'espériez.
J'ai déjà entendu parler de COBOLunit, mais je ne pense pas non plus qu'il soit actuellement maintenu (https://sites.google.com/site/cobolunit/download).
notre équipe développe un logiciel d'entreprise pour la gestion des concessionnaires automobiles/Camions/Ag dont la grande majorité est en AcuCOBOL.
nous avons pu faire quelques percées en utilisant peut-être junit (unit testing for java) pour effectuer et évaluer les tests de COBOL unit.
cela nécessitait un adaptateur de test personnalisé qui peut servir de tuyauterie et de câblage pour les données entre les tests COBOL unit et le cadre Junit. Dans l'application à tester, nous aurons alors besoin d'ajouter/concevoir des crochets qui évalueront l'entrée comme données de cas d'essai, effectuer le test auquel les données se rapportent, et rendre compte des résultats à l'adaptateur. Nous sommes au début de cette expérience et nous n'avons pas dépassé de beaucoup la phase "c'est possible" dans "c'est précieux". Le premier problème prévisible (qui, je pense, existe dans tous les tdd) est de savoir comment intégrer des harnais dans le programme.