在COBOL应用程序中是否有可行的方法来使用测试驱动的开发（TDD）？

Question

有没有人遇到任何可行的方法来在COBOL应用程序中实现test-driven development（可能还有behavior-driven development）？

一种理想的解决方案将使事务（CICS）和批处理模式COBOL代码都进行单元和集成测试，而这些都是在DB2数据库和各种固定宽度数据集的常规组合之上。

我看过http://sites.google.com/site/cobolunit/，看起来很有趣。有没有人看到这很生气？奏效了吗？什么是陷阱？

只是为了让您的创意发挥作用，对于理想方法的一些“要求”：

• 必须允许进行集成测试以执行整个COBOL程序。
• 必须允许测试自我验证其结果（即，将断言声明为xUnit）
• 必须同时支持批处理模式和CICS COBOL。
• 应该在调用被测代码之前/之后，通过操纵工作存储，允许单元测试在COBOL程序中行使各个段落。
• 应该提供了自动执行一系列测试（套件）并报告总体结果的功能。
• 应该支持使用在测试之前设置并在测试之后拆除的测试数据夹具。
• 应该将测试与生产代码完全分开。
• 应该提供大约1：1的典型测试与生产代码比率（即，编写测试不应将编写的代码量乘以太多，以免维护的总成本增加而不是减少）] >
• 不应
要求COBOL开发人员学习另一种编程语言，除非这与上述要求直接冲突。
• 可以
支持代码覆盖率报告。
• [Could
鼓励在代码本身中采用不同的设计模式，以使代码更易于测试。

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

仅提醒您，我在这里寻找的是关于实现此类目标的最佳方法的实用建议-我不一定要预包装解决方案。我很高兴看到一个示例，其中有人成功地在COBOL中使用了TDD，并提供了有关什么有效和哪些无效的一些指导和技巧。

有没有人遇到任何可行的方法来在COBOL应用程序中/针对COBOL应用程序实施测试驱动的开发（以及潜在的行为驱动的开发？理想的解决方案应同时启用...

Answer 1

也许签出QA Hiperstation。不过可能会花费很多（就像其他所有大型机产品一样）。

Answer 2

无论您如何构建/运行单元测试，您都可能需要总结一下测试的执行情况以及所测试软件的测试程度。

Answer 3

此答案可能不像您（和我）希望的那样简单。