WCG*_*PR0 27 c++ python unit-testing
我有一个我用C++创建的静态库,并希望使用驱动程序代码进行测试.
我注意到我的一位教授喜欢使用python进行测试,但他只是使用随机测试参数执行程序(在这种情况下不是库,而是可执行文件).
我想采用这种方法,但我意识到这是一个库,没有主要功能; 这意味着我应该创建一个Driver.cpp类,或者使用SWIG或boost python将库包装到python中.
我打算做后者,因为它似乎更有趣,但从逻辑上讲,我觉得尝试将库包装到另一种语言只是为了测试它而不是用它的母语测试它会有更多的错误.
用不同的语言测试程序是现实世界中公认的做法,还是这种不好的做法?
jwd*_*jwd 27
我想说最好测试一下您的用户将会接触到的API.其他测试也很好,但这是最重要的方面.
如果您的用户要编写链接到您的库的C/C++代码,那么以相同的方式使用您的库进行测试会很好.
如果你要发布一个Python包装器(为什么不呢?)那么你应该进行Python测试.
当然,这也有一个方便的方面.在Python中编写测试可能更容易,并且您可能有时间限制,使其更具吸引力等.
我想我所说的是:测试与被测代码的语言不同(例如,测试REST API是完全正常的)没有任何内在错误,但要确保你有面向公众的测试API至少.
除此之外,术语:
我不认为你所描述的测试类型是通常意义上的"单元测试".可能"功能测试"会更准确.
单元测试通常测试一个非常小的组件 - 例如函数调用 - 可能是一个更大的功能.像这样的单元测试通常是"白盒"测试,因此您可以看到代码的内部工作原理.
从用户的角度测试某些东西(例如教授的命令行测试)是"黑盒子"测试,并且在这些示例中处于更多功能级别而不是"单元"级别.
我相信很多人可能不同意这一点 - 但这并不是一套严格定义的术语.
要记住以下几点:
如果您在编写代码时编写测试,那么,无论如何,使用最适合的语言来为您提供快速反馈.这可以实现快速的测试代码循环(并且也很有趣).但是.
始终用消费者的语言编写完善的测试.您的客户/消费者如何调用您的功能?他们会用什么语言?使用相同的语言可以在生命周期的后期最小化集成问题.
为什么不呢,这是一个很棒的主意,因为您真正了解您正在像黑匣子一样测试该单元。
当然,可能会涉及到技术问题,如果你需要模拟被测单元的某些部分怎么办,这在不同的语言中可能会很困难。
不过,这是集成测试的常见做法,我见过很多由外部工具驱动的程序,例如来自 selenium 的网站或来自 Cucumber 的应用程序。这两个都可以被认为与自定义 python 脚本相同。
如果您认为集成测试和单元测试之间的区别在于在任何给定时间测试的事物的数量,那么您不应该这样做的唯一原因是工具支持。
这实际上取决于你试图测试的是什么.使用与您正在测试的代码相同的语言编写单元测试几乎总是有意义的,这样您就可以构建测试中的对象或调用测试中的函数,这两者都可以用同一种语言轻松完成,并验证他们正常工作.但是,有些情况下使用不同的语言是有意义的,即:
集成测试,可以同时运行多个不同的组件或应用程序.
验证无法在语言中测试的编译或解释失败的测试本身,因为您正在验证语言级别是否发生错误.
#1的示例可能是启动多个彼此连接的不同服务器的程序,向服务器发出请求并验证这些响应.或者,作为一个更简单的示例,一个程序只是将被测试的应用程序作为子进程分叉,并验证它是否为给定的输入生成了预期的输出.
#2的示例可能是一个程序,用于验证某个C++代码是否会产生静态断言失败,或者如果有人试图使用它,则故意禁止的特定模板实例化将导致编译失败.
要回答你的大问题,用不同的语言编写测试本身并不错.无论是什么使得测试更方便编写,更容易理解,对实现更改更加健壮,对回归更敏感,以及更好地定义良好测试的任何一个属性将是一个很好的理由以一种方式编写测试.如果这意味着用另一种语言编写测试,那就去吧.话虽这么说,小单元测试通常需要能够直接调用被测项目,在大多数情况下,这意味着用与被测组件相同的语言编写单元测试.
归档时间: |
|
查看次数: |
3128 次 |
最近记录: |