剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
DocTest 1.0的Ruby版本发布了
作者 Sebastien Auvray译者 贾晓楠 发布于 2008年7月13日 下午9时11分
一年前Tom Locke和Roger Pack分别实现了各自的Ruby DocTest（doctest来自于Python标准库）。如今Nic博士也在从事这项工作。DocTest可以方便地根据标准命令解释器（IRB for Ruby）的输出生成测试，并剪贴到文档串（docstring）中。
在IRB中进行测试，复制/粘贴你的输出，把它作为函数的注释：
# doctest: Add 5 and 5 to get 10# >> five_and_five# => 10def five_and_five5 + 5end
然后你可以这样来运行测试：
$ rubydoctest five.rb
=== Testing 'five.rb'...OK | Add 5 and 5 to get 101 comparisons, 1 doctests, 0 failures, 0 errors
以上实验采用的是git存储库中最新的源程序。不久后还会有一个升级包可用。
这样的文档串驱动测试有几个优点：
-
熟悉IRB现场测试的人会觉得它很用起来很自然。
-
测试时只需要观察一个地方。
-
简单。
……还有几个缺陷：
-
应避免很长的文档串，如果有的话，要把它放在单独的测试文件中。
-
不支持某些复杂的断言测试。
-
测试大量的输出可能会觉得冗长乏味。
Duane Johnson在Tom Locke的存储库上融合了一些改进，成了现在的1.0版 。
可以看一看使用DocTest的演示录像 。
InfoQ采访了Duane Johnson，谈一谈DocTest和文档串驱动测试。
InfoQ：首先，是什么促使你写DocTest的？我听说你研究了前两个实现。
Duane Johnson：我目前正致力于改进一个大型Ruby项目（memorypress.com）， 它只有很少的测试和文档。为了让它更完善，我们肯定需要在适当的地方做一些测试，避免不小心造成破坏。问题是，我的大部分“测试”时间都花在irb控制台 上了，因为我们不是总清楚测试进行到哪了以及如何应对。换句话说，测试对于我来说是种探索性工作——我需要看到程序是不是按照我明确规定的那样运行。 Ruby DocTest是个完美的结合，因为我可以把成功的实验输出复制到代码库中，并进行完整的核对测试。
最新的代码都在github上吗？它是不是融合了上一版的DocTest？你都增加了些什么？
是的，那儿有最新的代码。在本周早些时候，在得到Tom Locke的许可后，我从他的项目弄出了一个分支，放在github.com/tablatom/rubydoctest， 在里面加入了我的更新。我发现Tom写的代码读起来很顺，而且他通过eval（动态执行代码，而不是像Python的doctests那样直接测试字符 串）比较结果的方法非常棒。例如能成功地比较Ruby的无序哈希。我也参考了Roger Pack的主意，把doctest放到ruby源代码的注释中。我并没有借用Roger的程序（在code.google.com上），但借用了他的主意。现在，Ruby DocTest有两个选项，一是Roger的“内嵌doctest”风格，一是Tom的“标记文件的分立文档”风格。
你对现有的Ruby测试框架满意吗？
既满意又不满意。我还是有点喜欢rspec的。但在我的工作流程中，我发现自己总是在追赶代码，因为懒得切换到其他的 文件（或者创建一个文件）去写测试。我经常有一种为琐事操心的感觉，就是当我应该对方法测试一些边界情况时，却放弃了，因为那时候我脑子里还有许多其他东 西。要是我能在那放一个irb会话，我想，就能符合我90%的需求了。所以我就这么干了。
DocTest不在BDD周期中吗？
不在。它不是一个测试先行的方法。刚才已经提到了，我目前的需求，是给那些没有经过严格测试的已有项目建立文档。
DocTest要代替其他的单元测试框架吗？或者仅是一个额外的工具？
老实说，我还不知道。对我来说，这是个写测试的新方法。所以我还会继续完善它，相信很快就会有答案的。我觉得前面所说的目标已经实现90%了……可能还有一些地方，更适合使用传统的rspec或者Test::Unit用例。
DocTest对代码的注解是否会妨碍阅读呢？
我想，doctest的迁移步骤应该是这样的：
-
你写了一些代码，然后增加一两行内嵌doctest注释；
-
你修改了另一些代码，然后回到原始代码；
-
你添加了更多的测试用例，但是测试的数量（或长度）变得太大，因此你把它们移到单独的*.doctest文件里；
-
最后，你有了一个较完整的标记文件集合，还有有代码例子作为文档，其中包括指令和注释。
边写代码边写测试的一个有趣的副作用之一，是鼓励你让ruby源文件更加独立——换句话说，最好能够“动态执行 （eval）”文件而不出现任何依赖错误，而这正是doctests所要求的。我发现只要让一个文件摆脱掉一系列复杂的隐藏条件（就像Rails文件那 样），测试起来就容易得多。而且我对每个文件的依赖也更清楚了。
.gif)
没有回复
回复