有没有人遇到任何可行的方法在COBOL应用程序中实现测试驱动开发(以及潜在的行为驱动开发)?
理想的解决方案将支持事务(CICS)和批处理模式cobol的单元和集成测试,它们位于DB2数据库和各种固定宽度数据集的通常组合之上。
我见过http://sites.google.com/site/cobolunit/,看起来很有趣。有没有人看到过这种愤怒的工作?它有用吗?有什么问题?
只是为了让您的创意充满活力,为理想的方法提出一些“要求”:
欢迎评论上述要求的有效性/适当性。
提醒一下,我在这里寻找的是关于实现这些事情的最佳方式的良好实用建议 - 我不一定期望预先打包的解决方案。我很高兴看到有人在cobol中成功使用TDD的例子,以及一些有效和无效的指导和问题。
答案 0 :(得分:1)
也许请查看QA Hiperstation。可能会花费很多(就像其他所有大型机产品一样)。
很久以前只是简单地使用它,所以不能声称自己是专家。我用它在COBOL / CICS / DB2 / MQ-SERIES类型的环境中运行并验证一系列回归测试,发现它非常有效和灵活。
我想说这可能是你谜题的一部分,但肯定不是全部。
答案 1 :(得分:0)
无论您如何构建/运行单元测试,您都可能需要总结测试的效果以及所得软件的测试结果。
请参阅专为IBM COBOL设计的SD COBOL Test Coverage tool。
答案 2 :(得分:0)
这个答案可能不像你(和我)希望的那么容易。
之前我听说过COBOLunit,但我也认为它目前没有得到维护(https://sites.google.com/site/cobolunit/download)。
我们的团队开发了一个企业软件产品,用于管理汽车/卡车/ Ag经销商,其中绝大部分是AcuCOBOL。
我们能够在使用junit(java的单元测试)执行和评估COBOL单元测试时打破一些基础。
这需要一个自定义测试适配器,它可以作为COBOL单元测试和Junit框架之间数据的管道和接线。在要测试的应用程序中,我们需要添加/设计钩子,将输入作为测试用例数据进行评估,执行与数据相关的测试,并将结果报告给适配器。我们正处于这个实验的开始阶段,并没有超过“它可能”阶段进入“它有价值”。第一个可预见的障碍(我认为存在于所有tdd中)是如何在程序中构建线束。