在COBOL应用程序中使用测试驱动开发是否有可行的方法?

Pau*_*ell 23 tdd bdd cobol

有没有人遇到过在COBOL应用程序中实现测试驱动开发(以及可能的行为驱动开发)的任何可行方法?

理想的解决方案将支持事务(CICS)和批处理模式cobol的单元和集成测试,它们位于DB2数据库和各种固定宽度数据集的通常组合之上.

我见过http://sites.google.com/site/cobolunit/,看起来很有趣.有没有人看到过这种愤怒的工作?它有用吗?有什么问题?

只是为了让您的创意成果流动起来,对理想方法有一些"要求":

  • 必须允许集成测试来执行整个cobol程序.
  • 必须允许测试自我认证他们的结果(即使断言成为la xUnit)
  • 必须支持批处理模式和CICS cobol.
  • 应该允许单元测试通过在调用测试代码之前/之后操作工作存储来在cobol程序中执行单个段落.
  • 应该提供自动执行一系列测试(套件)和报告整体结果的能力.
  • 支持使用在测试之前设置并随后拆除的测试数据夹具.
  • 应该将测试与生产代码完全分开.
  • 提供大约1:1的生产代码比率的典型测试(即编写测试不应该将编写的代码量乘以使维护的总体成本上升而不是下降)
  • 不应该要求COBOL开发人员学习另一种编程语言,除非这与上述要求直接冲突.
  • 可以支持代码覆盖率报告.
  • 可以鼓励在代码本身中采用不同的设计模式,以使代码更容易测试.

欢迎评论上述要求的有效性/适当性.

只是提醒一下,我在这里寻找的是关于实现这些事情的最佳方式的良好实用建议 - 我不一定期望预先打包的解决方案.我很高兴看到有人在cobol中成功使用TDD的例子,以及一些有效和无效的指导和问题.

Nea*_*alB 2

也许可以查看QA Hiperstation。但它可能会花费很多(就像所有其他大型机产品一样)。

很久以前它只是简单地使用过它,所以我不能自称是专家。我用它在 COBOL/CICS/DB2/MQ-SERIES 类型环境中运行和验证了一系列回归测试,发现它非常有效和灵活。

我想说这可能是你拼图的一部分,但肯定不是全部。