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

前端之家收集整理的这篇文章主要介绍了tdd – 在COBOL应用程序中使用测试驱动开发是否有可行的方法?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
有没有人在COBOL应用程序中实现测试驱动开发(以及可能的行为驱动开发)的任何可行方法

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

我看过http://sites.google.com/site/cobolunit/,看起来很有趣。有没有人看到这个工作在愤怒?它有效吗什么是坏处?

只要让您的创意果汁流动,一些理想方法的“要求”

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

对上述要求的有效性/适用性表示欢迎。

只是提醒一下,我在这里寻找的是对实现这些事情的最佳方式的良好实用建议 – 我不一定期望预先打包的解决方案。我很高兴有人在cobol中成功使用TDD的例子,以及一些有用的指导和帮助,什么没有。

可能要查看 QA Hiperstation.可能花费很多(就像每个其他大型机产品一样)。

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

我会说这可能是你的难题之一,但肯定不是整个事情。

猜你在找的设计模式相关文章