在编写测试时如何避免重新实现正在测试的代码?
(我在 RoR 中使用 rspec,但我相信这个问题与任何测试系统相关。)
我经常发现自己在测试套件中做这种事情:
actual_value = object_being_tested.tested_method(args)
expected_value = compute_expected_value(args)
assert(actual_value == expected_value, ...)
问题是我的compute_expected_value() 实现/code> 通常最终会模仿 object_being_tested.tested_method()
,因此这实际上不是一个好的测试,因为它们可能具有相同的错误。
这是一个相当开放性的问题,但是人们使用什么技术来避免这个陷阱呢? (针对该主题的优秀论文的指导而授予积分......)
(I'm using rspec in RoR, but I believe this question is relevant to any testing system.)
I often find myself doing this kind of thing in my test suite:
actual_value = object_being_tested.tested_method(args)
expected_value = compute_expected_value(args)
assert(actual_value == expected_value, ...)
The problem is that my implementation of compute_expected_value()
often ends up mimicking object_being_tested.tested_method()
, so it's really not a good test because they may have identical bugs.
This is a rather open-ended question, but what techniques do people use to avoid this trap? (Points awarded for pointers to good treatises on the topic...)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
通常(对于手动编写的单元测试)您不会计算预期值。相反,您只需针对给定参数的测试方法的预期结果进行断言。也就是说,你会得到这样的结果:
在自动生成参数(甚至正在执行的测试方法)的其他测试场景中,你需要设计一个简单的预言机,它会给你预期的结果(或者应该保持的不变量)以获得预期结果)。 Pex、Randoop,ASTGen , 和 UDITA 启用此类测试。
Usually (for manually written unit tests) you would not compute the expected value. Rather, you would just assert against what you expect to be the result from the tested method for the given args. That is, you would have something like this:
In other testing scenarios where the arguments (or even test methods being executed) are generated automatically, you need to devise a simple oracle which will give you the expected result (or an invariant that should hold for the expected result). Tools like Pex, Randoop, ASTGen, and UDITA enable such testing.
好吧,这是我的两分钱
a)如果预期值的计算很简单,并且除了生成预期结果的测试用例之外不包含任何业务规则/条件,那么它应该足够好......请记住,您的实际代码将尽可能通用。
在某些情况下,您会在预期的方法中遇到问题,但您可以轻松查明失败的原因并修复它。
b)在某些情况下,预期值无法轻松计算,在这种情况下,可能有带有结果的平面文件,或者可能有某种恒定的预期值,正如您自然希望的那样。
此外,还有一些测试,您只想验证是否调用了特定方法,并且您已经完成了对该单元的测试。记住在测试时使用所有这些不同的范例,并始终记住保持简单
Well here are my two cents
a) if the calculation of the expected value is simple and does not encompass any business rules/conditions in there apart from the test case to which it is generating the expected result then it should be good enough... remember your actual code will be as generic as possible.
Well there are cases where you will run into issues in the expected method but you can easily pin point the cos of failure and fix it.
b) there are cases when the expected value cannot be easily calculated in that case probably have flat files with results or probably some kind of constant expected value as naturally you would want that.
Also then there are tests where in you just want to verify whether a particular method was called or not and you are done testing that unit.. remember to use all these different paradigms while testing and always remember KEEP IT SIMPLE
你不会那样做的。
你不用计算期望值,你已经知道了。它应该是您的测试中定义的常量值。 (或者是由已经测试过的其他函数构建的。)
you would not do that.
you do not compute the expected value, you know it already. it should be a constant value defined in your test. (or is constructed from other functions that have already been tested.)