tdd - 是否有一种可行的方法可以在 COBOL 应用程序中使用测试驱动开发 (TDD)？

Question

有没有人遇到过任何可行的实现方法 test-driven development (以及可能的 behavior-driven development )在/用于 COBOL 应用程序？

理想的解决方案将支持事务 ( CICS ) 和批处理模式 COBOL 代码的单元测试和集成测试，位于 DB2 的常见组合之上。数据库和各种固定宽度数据集。

我见过http://sites.google.com/site/cobolunit/ ，看起来很有趣。有谁见过这在愤怒中工作吗？有效吗？有哪些陷阱？

为了让您的创意源源不断，理想方法的一些“要求”:

• 必须允许集成测试来运行整个 COBOL 程序。
• 必须允许测试 self 证明其结果(即按照 xUnit 进行断言)
• 必须支持批处理模式和 CICS COBOL。
• 应该允许单元测试通过在调用被测代码之前/之后操作工作存储来执行 COBOL 程序中的各个段落。
• 应该提供自动执行一系列测试(套件)并报告总体结果的能力。
• 应支持使用在测试前设置并在测试后拆除的测试数据装置。
• 应该将测试与生产代码完全分开。
• 应该提供大约 1:1 的典型测试与生产代码比率(即，编写测试不应将编写的代码量增加太多，从而导致总体维护成本反而上升羽绒)
• 不应要求 COBOL 开发人员学习另一种编程语言，除非这与上述要求直接冲突。
• 可以支持代码覆盖率报告。
• 可以鼓励在代码本身中采用不同的设计模式，以使代码更易于测试。

欢迎对上述要求的有效性/适当性提出意见。

只是提醒一下，我在这里寻找的是关于实现这些事情的最佳方式的实用建议 - 我不一定期待预先打包的解决方案。我很乐意看到有人在 COBOL 中成功使用 TDD 的示例，以及一些关于什么有效、什么无效的指导和陷阱。

Answer 1

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

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

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