我有一个同事为对象填充单元测试,这些对象用随机数据填充他们的字段.他的理由是它提供了更广泛的测试,因为它将测试许多不同的值,而普通测试仅使用单个静态值.
我给了他很多不同的理由,主要是:
随机值意味着测试不是真正可重复的(这也意味着如果测试可以随机失败,它可以在构建服务器上执行此操作并中断构建)
如果它是一个随机值并且测试失败,我们需要a)修复对象并且b)强迫我们每次都测试该值,所以我们知道它有效,但由于它是随机的,我们不知道它的值是什么
另一名同事补充道:
如果我正在测试异常,则随机值将无法确保测试最终处于预期状态
随机数据用于清除系统和负载测试,而不是用于单元测试
任何人都可以添加其他原因我可以让他让他停止这样做吗？
(或者,这是一种可接受的编写单元测试的方法,我和我的其他同事都错了？)
有妥协.你的同事实际上是在做某事,但我认为他做错了.我不确定完全随机测试是非常有用的,但它肯定不是无效的.
程序(或单元)规范是存在一些满足它的程序的假设.程序本身就是该假设的证据.单元测试应该是试图提供反证据来反驳该程序根据规范工作.
现在,您可以手动编写单元测试,但这确实是一项机械任务.它可以自动化.您所要做的就是编写规范,机器可以生成大量的单元测试,试图破坏您的代码.
我不知道你使用的语言,但请看这里:
Java http://functionaljava.org/
Scala(或Java) http://github.com/rickynils/scalacheck
Haskell http://www.cs.chalmers.se/~rjmh/QuickCheck/
.NET:http: //blogs.msdn.com/dsyme/archive/2008/08/09/fscheck-0-2.aspx
这些工具将把您精心设计的规范作为输入,并使用自动生成的数据自动生成任意数量的单元测试.他们使用"缩小"策略(您可以调整)来找到最简单的测试用例来破坏您的代码并确保它能很好地覆盖边缘情况.
快乐的测试!
这种测试称为Monkey测试.如果做得好,它可以从真正黑暗的角落抽出虫子.
为了解决您对可重复性的担忧:正确的方法是记录失败的测试条目,生成单元测试,探测特定错误的整个系列 ; 并在单元测试中包括导致初始故障的一个特定输入(来自随机数据).
这里有一个中途的房子有一些用处,这是为你的PRNG播种常数.这允许您生成可重复的"随机"数据.
就个人而言,我认为有些地方(恒定的)随机数据在测试中很有用 - 在你认为你已经完成了所有仔细考虑过的角落后,使用PRNG的刺激有时可以找到其他东西.
在" 美丽代码 "一书中,有一章称为"美丽测试",他在其中介绍了二进制搜索算法的测试策略.一段称为"随机测试行为",其中他创建随机数组以彻底测试算法.您可以在Google图书,第95页上在线阅读其中一些内容,但这本书值得一试.
所以基本上这只是表明生成随机数据进行测试是一个可行的选择.
如果您正在进行TDD,那么我认为随机数据是一种很好的方法.如果您的测试是用常量编写的,那么您只能保证您的代码适用于特定值.如果您的测试随机地使构建服务器失败,则可能存在测试编写方式的问题.
随机数据将有助于确保任何未来的重构都不会依赖于魔法常量.毕竟,如果您的测试是您的文档,那么常量的存在是否意味着它只需要对这些常量起作用？
我夸大了但是我更喜欢将随机数据注入我的测试中,作为"此变量的值不应影响此测试结果"的标志.
我会说,如果你使用一个随机变量,然后根据该变量分叉你的测试,那就是气味.
观察测试的人的一个优点是任意数据显然不重要.我看过太多涉及数十个数据的测试,很难分辨出那种方式需要什么,以及恰好是这样.例如,如果使用特定的邮政编码测试地址验证方法,并且所有其他数据都是随机的,那么您可以非常确定邮政编码是唯一重要的部分.
我赞成随机测试,我写它们.但是,它们是否适用于特定的构建环境以及它们应包含在哪些测试套件中是一个更细微的问题.
在本地运行(例如,在你的开发盒上过夜)随机测试发现了明显和模糊的错误.这些模糊不清的东西足够神秘,我认为随机测试真的是唯一能够将它们清除掉的现实测试.作为测试,我通过随机测试发现了一个难以发现的bug,并且有六个破解开发人员审查了它发生的功能(大约十几行代码).没有人能够发现它.
许多反对随机数据的论据都是"测试不可重复"的风格.然而,一个写得很好的随机测试将捕获用于启动随机化种子的种子并在失败时输出它.除了允许您手动重复测试之外,这还允许您轻松创建新测试,通过对该测试的种子进行硬编码来测试特定问题.当然,手动编写覆盖该案例的显式测试可能更好,但懒惰有其优点,这甚至允许您从失败的种子中自动生成新的测试用例.
然而,你提出的我无法辩论的一点是它打破了构建系统.大多数构建和持续集成测试都希望测试每次都能做同样的事情.因此,随机失败的测试会造成混乱,随机失败并指责无害的变化.
然后,解决方案仍然是将随机化测试作为构建和CI测试的一部分运行,但是使用固定种子运行它,进行固定次数的迭代.因此测试总是做同样的事情,但仍然探索一堆输入空间(如果你运行多次迭代).
在本地,例如,在更改相关类时,您可以自由运行它以进行更多迭代或使用其他种子.如果随机测试变得越来越流行,您甚至可以想象一组特定的测试,这些测试已知是随机的,可以使用不同的种子运行(因此随着时间的推移而增加覆盖率),并且失败并不意味着相同的事情作为确定性CI系统(即,运行不会以1:1与代码更改关联,因此当事情失败时,您不会指出特定的更改).
随机测试有很多要说的,特别是编写良好的测试,所以不要太快解除它们!
如果它是一个随机值并且测试失败,我们需要a)修复对象并且b)强迫我们每次都测试该值,所以我们知道它有效,但由于它是随机的,我们不知道它的值是什么
如果您的测试用例没有准确记录测试内容,那么您可能需要重新编写测试用例.我总是希望有一些我可以参考测试用例的日志,以便我确切地知道是什么原因导致它失败,无论是使用静态数据还是随机数据.
你的同事正在进行模糊测试,尽管他不知道.它们在服务器系统中特别有价值.
京公网安备 11010802040832号 | 京ICP备19059560号-6 