Maybe check out QA Hiperstation. It could cost a lot though (just like every other mainframe product).
It only used it briefly a long time ago, so I cannot claim to be an expert. I used it to run and verify a battery of regression tests in a COBOL/CICS/DB2/MQ-SERIES type environment and found it to be quite effective and flexible.
I would say this could be one of the pieces of your puzzle, but certainly not the whole thing.
This answer may not be as easy as you (and I) had hoped.
I have heard about COBOLunit before, but I also don't think it's currently being maintained.
Our team develops an enterprise software product for managing Auto/Truck/Ag dealerships the vast majority of which is in AcuCOBOL.
We were able to break some ground in possibly using JUnit (unit testing for Java) to execute and evaluate COBOL unit tests.
This required a custom test adapter that can serve as the piping and wiring for data between the COBOL unit tests and the JUnit framework. In the application to be tested we will then need to add/design hooks that will evaluate the input as test case data, perform the test to which the data relates, and report results to the adapter.
We are at the beginning of this experiment and haven't gotten much past the "it's possible" phase into "it's valuable". The first foreseeable snag (which I think exists in all TDD) is how to build harnesses into the program.
发布评论
评论（3）
也许可以查看 QA Hiperstation。但它可能会花费很多（就像所有其他大型机产品一样）。
很久以前它只是简单地使用过它，所以我不能自称是专家。我用它在 COBOL/CICS/DB2/MQ-SERIES 类型环境中运行和验证了一系列回归测试，发现它非常有效和灵活。
我想说这可能是你拼图的一部分，但肯定不是全部。
Maybe check out QA Hiperstation. It could cost a lot though (just like every other mainframe product).
It only used it briefly a long time ago, so I cannot claim to be an expert. I used it to run and verify a battery of regression tests in a COBOL/CICS/DB2/MQ-SERIES type environment and found it to be quite effective and flexible.
I would say this could be one of the pieces of your puzzle, but certainly not the whole thing.
无论您如何构建/运行单元测试，您可能都需要总结测试的执行情况以及生成的软件的测试情况。
请参阅专门为 IBM COBOL 设计的 SD COBOL 测试覆盖率工具。
Regardless of how you build/run unit tests, you likely need a summary of how well the tests are doing and how well tested the resulting software is.
See our SD COBOL Test Coverage tool, specifically designed for IBM COBOL.
这个答案可能不像你（和我）所希望的那么容易。
我以前听说过COBOLunit，但我也不认为它目前正在维护。
我们的团队开发了一款企业软件产品，用于管理汽车/卡车/农业经销商，其中绝大多数都在 AcuCOBOL 中。
我们能够在使用 JUnit（Java 单元测试）来执行和评估 COBOL 单元测试方面取得一些进展。
这需要一个自定义测试适配器，它可以充当 COBOL 单元测试和 JUnit 框架之间数据的管道和接线。在要测试的应用程序中，我们需要添加/设计挂钩，将输入评估为测试用例数据，执行与数据相关的测试，并向适配器报告结果。
我们正处于这个实验的开始阶段，还没有从“这是可能的”阶段进入“它是有价值的”阶段。第一个可预见的障碍（我认为所有 TDD 中都存在）是如何将工具构建到程序中。
This answer may not be as easy as you (and I) had hoped.
I have heard about COBOLunit before, but I also don't think it's currently being maintained.
Our team develops an enterprise software product for managing Auto/Truck/Ag dealerships the vast majority of which is in AcuCOBOL.
We were able to break some ground in possibly using JUnit (unit testing for Java) to execute and evaluate COBOL unit tests.
This required a custom test adapter that can serve as the piping and wiring for data between the COBOL unit tests and the JUnit framework. In the application to be tested we will then need to add/design hooks that will evaluate the input as test case data, perform the test to which the data relates, and report results to the adapter.
We are at the beginning of this experiment and haven't gotten much past the "it's possible" phase into "it's valuable". The first foreseeable snag (which I think exists in all TDD) is how to build harnesses into the program.