c# – C中的可测试性设计
|
我想了解在C中设计可测试应用程序的最佳方法,也许与C#相比(因为它是我的背景,非常适合测试)
我习惯于编码接口,依赖注入,控制框架的反转和模拟对象.由于C#有很多不同的语言特性,我不确定有多少模式仍然适用.我还想象C的独特功能/限制可能会带来不同的测试策略. 我看过单元测试框架,我喜欢Google Test,但是编写我的新代码以尽可能测试它也很重要. >是否有任何可以推荐为C的开源项目 谢谢 解决方法
我现在处于完全相同的情况.来自C#背景,现在我正在编写新的(并扩展遗留的)C应用程序.
我想共享背景给我们留下了常见的问题.令我感到惊讶的是,遗留应用程序中的依赖关系与我们的类紧密相关. 正如您似乎强调的那样,关注点可能是C#中的最佳实践并不是C语言中的最佳方法.经过大量的研究,我自己的一些Stack Overflow问题以及一些原型设计,我最终得到了一个C架构,它在很多方面反映了我在C#中最好的效果. 以下是我使用的主要原则： >依赖注入 我们的类的构造函数接受我们可能想要作为参数模拟的依赖项的接口.在某些情况下,这意味着编写依赖项的包装器,例如boost :: filesystem,它主要在模板化头文件中实现.在我看来,值得花费很少的努力,因为我们可以更加松散地将我们与可能改变或被我们交换的库耦合在一起,并且它允许我们使用模拟实现进行单元测试. 这应该是不言而喻的,但是在编写类时编写测试可以让您在可测试性方面检查您的设计.我不关心你先测试,做TDD,或者你称之为什么,我的理念是在你开始在代码库中使用类之前编写测试. 到目前为止,我使用过Cxxtest(遗留应用)和Google Test. Google Test在执行时提供了许多灵活的选项,以确定您运行的测试集.我们将类命名约定分为UnitTest_xxxx和IntegrationTest_xxxx.然后在命令行,我可以告诉gtest只运行一个名称,另一个或两者的测试.然后我的构建服务器可以在晚上对整个测试套件执行长时间运行的测试,但是每次检查都要进行单元测试.Cxxtest可以做同样的事情,但是工作量更多,并且由于很多原因而且通常很笨拙. 依赖注入的明显好处是在测试期间使用模拟对象.人们可以简单地编写每个界面的虚假实现,但Google Mock允许快速旋转虚假对象,并提供您期望从一个好的.NET模拟框架(如Moq或RhinoMock)进行的典型检查. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |